I have said it time and again, one of the things I *love* about React over it's alternatives, and even react-like alternatives is React is second to none when it comes to properly displaying error messages and warnings in the console.
While I like the example, it might have been easier to follow with the pieces broken up a bit.
Also, I think at this point, given the power of Array.from + array methods, combined with fat-arrow methods that most of what Ramda and the like (lodash/underscore) offer is of more limited value.
Regarding bugs, it's already been shown to be less than true that static typing prevents more bugs than the time it takes[0]. IMHO with clean modules, pure functions, attention to detail and good organization following a functionally minded paradigm, static types add *very* little, other than some level of documentation.
Personally, I've rarely seen the point, and I've worked with statically typed languages for well over a decade of my career. JS happens to be a favorite language of mine... I like that JS makes it easy to continue working as opposed to breaking the world apart. I think the biggest issue is that the two things that should be first and foremost in defining a project tend to get punted until later...
The first being error handling. I'm working on a project right now, that swallows errors left and right, always returning a happy path. Internal node modules with only positive callbacks, and no error handling in sight. One must define errors as a top-level concern. When I design APIs, the return type is always Errorable<t> instead of X : IErrorable... in this way, there are a few properties on a wrapper object, { code, error, data:T } code should match the HTTP response code, error (nullable) will contain an error object with at *least* a "message" property and data will be the expected successful data. In this way the client can always check if response.error, quickly, cleanly. From there, a given client should have several error states, temporary/retry, permanent/no-retry and fatal (stop the world). The handling of these conditions should be in place before *any* other features... Error handling/display is a *critical* feature that should not be deferred/burried.
The second being proper handling of users/authentication/roles. This is a far second in terms of importance but is often done nearly as badly as consistent error handling.
Even though I mention types/interfaces wrt errors, that doesn't mean they have to be typed in code, just consistently implemented. Likewise, I don't like classical structure outside of UI bound contexts. There's no need for it. Functional flows and composition will almost always be cleaner and less buggy. The issues at play are more about diligence, testing, structure and review than they are typed or not. All the typing in the world won't prevent a buggy implementation, which is where *most* problems lay.
[0] https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.iypvaf25w
(copied from my comment in TFA)
Interesting concept. I'm not sure if this brings enough over webpack's options or things like aphrodite. Also, not sure if the component will create multiple style tags, or morph a single style tag in the header, which would probably be better.
It could be useful for reusable components.
While I agree with @machineghost and @xat, I want to state that I feel a lot of it comes down to incumbents who are more comfortable with other languages/platforms that tend to bring preconceptions in with them. A lot of web developers have far more experience with PHP, Java or C# than they do JavaScript itself. They've also attached far more energy into the Angular 1.x ecosystem than anything before it (regarding full JS platforms).
I do think that React will overtake Angular 1, and that Angular2 won't catch a lot of the ng1 users moving forward. I will make one statement regarding the two... React has some of the most clear, consistent and useful error messages in the console of any web tool that I've ever used as a whole. ng2 will silently just bork on template errors. And ng2 isn't much better.
I feel that a more functional approach is better with regards to predictable state and that not following more FP-oriented practices leads to a lot of wierd state issues that tend to be more prevalent when following the ng1 model specifically. $scope.$apply's existence is the single worst code smell in that ecosystem. React has evolved to adopt the usage of the broader tooling (cjs modules, babel, etc), while ng1 in particular works against that, and while ng2 is better, there's still a lot of alien parts baked in.
I'm working in ng1.x at my day job currently, and will say there are much bigger issues with organizing JS based projects with the average developer than react vs angular. On the flip side, I prefer frameworks that lead to code discovery, vs spending half my time in the search tab in my editor looking for the right file to edit.
I'm curious if webpack 2 will be closer... also, the separate function is more correct by design at the performance impact.
I also find it interesting that edges' runtime cost is so much higher than FF and Chrome here... Though in either case, the overhead for 1k modules doesn't seem too bad, these are really minimalistic modules, and 10ms for 1k of them doesn't seem horribly out of line. Especially in an SPA environment where they're likely only run once.
Better structure than a lot of ng apps out there... that said, Controllers in ng are actually constructor functions, and it would be better to have them named/treated as such. Beyond that, I'd probably throw babel-loader into the mix for .js, and use the ES2015 class syntax.
This is why I hate goofy DSLs... I don't think it's great... it's yet another meta language in an html-like language that you now have to know that only applies to angular.
Regarding bugs, it's already been shown to be less than true that static typing prevents more bugs than the time it takes[0]. IMHO with clean modules, pure functions, attention to detail and good organization following a functionally minded paradigm, static types add *very* little, other than some level of documentation. Personally, I've rarely seen the point, and I've worked with statically typed languages for well over a decade of my career. JS happens to be a favorite language of mine... I like that JS makes it easy to continue working as opposed to breaking the world apart. I think the biggest issue is that the two things that should be first and foremost in defining a project tend to get punted until later... The first being error handling. I'm working on a project right now, that swallows errors left and right, always returning a happy path. Internal node modules with only positive callbacks, and no error handling in sight. One must define errors as a top-level concern. When I design APIs, the return type is always Errorable<t> instead of X : IErrorable... in this way, there are a few properties on a wrapper object, { code, error, data:T } code should match the HTTP response code, error (nullable) will contain an error object with at *least* a "message" property and data will be the expected successful data. In this way the client can always check if response.error, quickly, cleanly. From there, a given client should have several error states, temporary/retry, permanent/no-retry and fatal (stop the world). The handling of these conditions should be in place before *any* other features... Error handling/display is a *critical* feature that should not be deferred/burried. The second being proper handling of users/authentication/roles. This is a far second in terms of importance but is often done nearly as badly as consistent error handling. Even though I mention types/interfaces wrt errors, that doesn't mean they have to be typed in code, just consistently implemented. Likewise, I don't like classical structure outside of UI bound contexts. There's no need for it. Functional flows and composition will almost always be cleaner and less buggy. The issues at play are more about diligence, testing, structure and review than they are typed or not. All the typing in the world won't prevent a buggy implementation, which is where *most* problems lay. [0] https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.iypvaf25w (copied from my comment in TFA)