We Keep Coding

What's the different between react-router and Next.js

i'm currently expolring ReactJS
i saw NextJS and React Router
Can anyone tell me what's the pro cons between the two. I'm not sure if it's right to compare the two, but from what i see, react-router already has SSR feature. So whats the benefit of using NextJS?
Thanks!

Next.js (see also alternatives like GatsbyJS and After.js) are full featured SSR/static site frameworks, so you get a lot of features out of the box if you need to generate a SSR static site. These frameworks have solved lots of problems, so adding a feature becomes as simple as reading the docs, rather than researching and coding on your own.
If you code your own setup with a standard React app and react-router then you might find yourself running into a lot of complexity and edge cases when you dig into SSR.
In short, if SSR is a core requirement definitely consider using a SSR React framework.

Jed's response sums it up pretty much, but here are some clarifications:
React router allows SSR, but does not implement it. You still need to make a server script that, at least, renders the app to a string and serve that to the client. You may need to do other things, like serve static files. NextJS does that for you.
SSR comes with a few caveats that NextJS also covers, mainly initial asynchronous functions (fetchs from APIs, for example). In a custom made system, you'll have to determine which functions you should call, usually based on the route, and pass the data to the components, usually with Redux
I'm currently working on webs with both systems, and both have some pros and cons.NextJS has a specific way to declare routes and a very different way of moving through them, but making a custom system that deals with everything that NextJS covers is quite the work. I would not recommend making everything yourself unless it's really needed, and maybe check alternatives like Gatsby if asynchronous loads aren't a concern

How to effectively apply version control for React components at scale?

This question is about possible higher-level approaches that one could take to applying version control to React components. Specifically, these components should be more on the "atomic" end of the spectrum, i.e. doing one thing powerfully in a variety of contexts.
Specifically, I'd like your thoughts on versioning such components at scale, whilst addressing issues such as:
Cross-project usability (i.e. <Button /> component in both of my React apps);
Theming (how themes and styles can be shared across these components); and
Dependencies (e.g. version 1.0.5 of <StackedButton /> depends on version 2.1.0 of <Button />)
I've been looking into Bitsrc.io as a possible tool to help me manage this. I've been largely addressing these issues by having quite a few (~10) Git repositories, each managing a loosely coupled set of components, e.g. text-components, layout-components, table-components, but I feel like I'm at a point, where with the number of components and the dependencies they have, further maintainability may be sacrificed if I make the wrong decision.

I've had some success using lerna; I think it might fit your needs pretty well. You basically would combine all 10 of your repositories in a single one, with each one now being a package within the repository.
Lot of advantages to this approach. Mainly, it lets you still have separate published packages, giving consuming apps flexibility on what they want/don't want to pull in, but it removes a lot of the overhead of having a lot of packages. It becomes much easier to make sweeping changes, and it's impossible for your packages to get out of sync, since they're always updated together. If you make a breaking change in one package that another package relies on, you would fix the package in the same PR as the breaking change.

Updating to Material-UI v1.x.x

My app currently uses Material-/ui v0.17.0 and in order for it to work with React v16.0.0 I have to upgrade to Material-UI v1.0.0.
I have seen the migration tool here. This just updates the import statements more or less. A lot of the props appear to have changed and are not backwards compatible. The tool actually would not work for me so
I manually updated all of my imports. It is almost looking like I have to rewrite the entire front end code of this app using the new updated v1.0.0 components. There has got to be a better way to do this. I understand that major version changes are "breaking" changes but this version upgrade may as well be an entirely new package. I cannot be the only person who has had to upgrade to v1.0.0 and am curious to how others have been able to successfully migrate over.

As you have noticed the API is not backward compatible and the migration guide is to be continued... I think there is a reason for that.
Although most of the components have their replacement, it looks like there is no straightforward way to migrate, especially because some components like autocomplete are not present in 1.x. If you heavily invested in restyling the components with touching the internals, you'll have even harder time, since in 1.x JSS is proposed way of styling.
The only way I see now is to rewrite it component by component. That's not something you'd like to read in the migration guide:)

For my specific project the solution seemed to be that I could use react v16.4.1 with material-ui v0.20.0. In doing so I had to drop react-tap-event-plugin which is not compatible with react versions >=16.4.0. This involved converting onTapEvent tags to onClick. Fortunately, by not having to upgrade the the new major version of material-ui, I did not have to update my components which was my fear.
All of this aside, I did spend some time converting material-ui components to v1.2.0 before I arrived at my solution which did not require these component modifications. When attempting to perform these changes, the documentation was sparse. I did find another Stack Overflow thread asking about the migration to v1.x.x here.
In that thread I linked to a couple of github issues that raised the same concern, and they are likely a valuable resource to keep your eye on if you yourself are trying to make this version transition.
[docs] 0.x => 1.x migration guide #7195
Codemod error when upgrading from v0.18.7 to v1.1.0 #11819
As well as some code someone documented when making the transition.
Here is a project where someone went through upgrading to mui 1.x.x from 0.x.x

Any 3rd party packages used by Angular 4 in run-time (except RxJS)?

Angular 4 uses some RxJS types in its public API as well as depends on RxJS internally.
Thinking further on this, it might be good to know if Angular uses other packages for parts of its run-time functionality, so we could use them as well. It might prevent us from introducing extra dependencies for the app by re-using them from Angular.
But looking into node_modules, every Angular 4 app contains a massive amount of packages. Obviously, most of them doesn't get included in the run-time app bundle. At the same time, some of them (like lodash) could be very desirable to use in your Angular app as well.
So, is Angular based on any other packages except RxJS and which of them could be used in our own code similar to RxJS?

Angular is pretty buffed up, meaning it already comes with predefined strategy on how you should accomplish things. I believe it's built on RxJS so you won't be able to get rid of it.
But you don't really have to use it. When you pack your app for production it will not include all of the node_modules packages, only the ones that were used.
If you want to use a JS library that's a lot less heavyweight, and comes less structured, look into react.js and vue.js

Although RxJS is certainly a big player in Angular's dependency pool, it's certainly not the only one, and not even the only one you'll need to depend on to use Angular.
Zone.js, for instance, is another key component in Angular's architecture that you'll need to depend on to use it. Although both libraries are used extensively in Angular, you are by no means mandated to use them – that being said, you'll get a lot more out of the framework if you understand Observables and Zones.
Other things you'll need to depend on are easily inspected in Angular-CLI's polyfills.js file; things like core.js that shim up Angular's ability to run on lower-common-denominator browsers (cough, IE). There's also multiple #angular/*-scoped modules you'll need for other pieces of the framework, such as forms and http.
My recommendation? Boot up a CLI project and see what ends up in the dependencies section of your package.json. RxJS and Zone.js are the big contenders, but you may be surprised by other names on the list.

Working with Angular 2 [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Our team is way too excited with the alpha release of Angular 2 and we're just eagerly waiting for it's stable release and getting started with it.
But during the ng-conf 2015 on Angular 2 by Misko, we came across following things which made me confused
TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
I'm not sure I've structured my question well, but above are my concerns before I start learning angular 2 because with their demonstration of angular 2 + typescript seemed like it's gonna involve a lot of earning curve for me and my team.
I'll really appreciate if someone can clarify on the above listed concerns I have.
Thanks.

TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is about static analysis for better type-safety. It also has a pretty nice suite of editor tools (e.g. WebStorm). You don't need it for performance. It's more a tool for helping you author. Personally though, I love it.
I've begun migrating some of my existing open-source libraries to TypeScript because it's so much easier to work with. For example, check out Task Runner before and after.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
A lot of ES6 features can be polyfilled. Check out https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Web components are also polyfillable (see here). In this case, I'd suggest you follow the Angular team's recommended practices for creating your components. Also perhaps keep an eye on what's coming out of the Polymer team in this regard.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
This sounds to me like premature optimization. Build for (plain) Angular first and optimize only if you notice performance problems in particular parts of your application.

TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is not required to use Angular2.
Most examples you see will use JavaScript:
classes (ES6)
decorators (ES7/Typescript)
types - (Typescript)
Except, browsers don't support those features yet so all Angular2 source will need to be transpiled to ES5.
So in ES5:
classes can be faked by extending prototypes
decorators can be faked using wrapper functions
types aren't really necessary to begin with, they're synctatic sugar added for safety
It would be unrealistic to expect existing users to inherit the risk of using experimental/bleeding-edge standards. As such, the documentation covers writing Angular2 apps in ES5, ES6/7, and Typescript.
Aside: I personally prefer not to use TypeScript. Traceur can be configured to support with experimental extensions for #decorators, and system.js provides a polyfill for the proposed es6-moduler-loader spec.
Here's a look at the Angular2 Documentation.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
As I said already, ES6 isn't officially supported yet in all browsers. Even if it were, most sites will still require a polyfill to provide backwards compatibility to older browsers.
One of the cool features of the es6-module-loader is the ability to dynamically load dependencies on the fly. By the time Angular2 is out of beta, it should be easy to incorporate this into your app as a feature-detection strategy.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing?
Not hard although you may need to use Angular2-specific web components. The reason being, Angular2 is more than a front-end web framework. It's can also be used for isomorphic (ie prerender on the back-end), native, and mobile apps. That means, touching the DOM directly is highly discouraged.
As for the creation of the components themselves... It's no different than creating any other component in Angular2. Unlike the old MVC model of grouping code by type (ie models, views, controllers), the component model encourages grouping code by context.
When you import a reusable component, it should come with any directives, services, etc required to use it.
For an example, see the I created. In addition to cloning the repo directly from GH, the code can be installed and imported directly via JSPM.
Simply import it, add the component class to your view directives and any <ng2-markdowm> element in your template will just work. It doesn't get much easier than that.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
There are 3 major performance improvements introduced in Angular2.
1. 2-way data binding is no longer the default
Elements that require data binding need to be explicitly marked in the template (ie don't fret, the new syntax makes this really simple). As a result the overhead required to do dirty checking on the DOM is dramatically reduced.
That means, no more $scope, $scope.apply(), and weird scoping rules in the HTML markup. Instead, the hierarchy of custom <elements> is defined in the Angular2 components.
2. Angular2 leverages the virtual DOM
jQuery made it extremely simple to directly manipulate the DOM. As a result, it also made it extremely easy for inexperienced developers to thrash the DOM and trigger layout reflows via frequent incremental updates.
The VDOM is basically a simplified in-memory representation of the DOM. Incremental updates get applied directly to the VDOM which later get applied to the actual DOM in batches.
Aside from network requests, DOM manipulation is JavaScript's greatest performance weakness. The VDOM on the other hand is an order of magnitude faster. Instead of expecting devs to follow 'best practices' by manually batching updates to the DOM, Angular handles batching transparently.
Fewer DOM manipulations = less UI rendering/reflows = a much more responsive user experience.
3. Angular2 runs on a background worker
This isn't exactly a new concept. Desktop GUIs have worked this way for years, it just wasn't technically possible the introduction of HTML5 background workers.
In most desktop applications, the main context runs synchronously+ and the UI runs asynchronously in it's own separate thread. That makes the user experience responsive regardless of whatever the application is doing in the main context.
+Note: This isn't necessarily true, but for clarity sake.
In the browser, all execution happens in the main context+. That means, every time Javascript has to block on a CPU-heavy operation, the user interface becomes unresponsive to the user. This is not ideal and makes for a lousy/inconsistent user experience.
+Note: In practice browser implementations vary greatly but lets keep things simple.
With web workers, it's possible to push everything but the DOM+ into a background worker context. Ideally, Javascript's should have little-or-no impact on UI responsiveness.
+Note: The DOM's state still needs to be accessible to the renderer.
One side-effect this transition is, the Angular2 architecture is now completely decoupled from the UI/DOM. Meaning, it's now possible to write UI adapters for other platforms (ex for IOS, Android, SmartTVs, etc) that run on the same Angular2 code natively.
React
As far as I can tell React is using all of the same performance improvements as Angular. They use the VDOM to batch updates, and mentioned native portability to other platforms so I assume they went through the same architectural change as Angular.
Honestly, using background processing to free up the UI is just another step in the evolution to reach feature parity with desktop applications.
Angular2 vs React
I encourage you to watch the video again all the way to the end. The presenter screwed up when he wrote the code so the live demo wasn't an honest comparison.
With that said, it doesn't really matter which is faster. Neither will be dramatically faster than the other but they'll both be dramatically more responsive and scalable compared to other UI frameworks.
Update:
Rewrote the section about web components to better answer the question.

Note that Angular 2.0 does promise to work well with Web Components and Polymer, but in the current stage, i.e. Angular 2.0 alpha, it doesn't work (see this). So you'll have to wait for a while I guess.