Echo JS 0.11.0

Wow.

Note: the repo in the link does not do tree shaking.

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.

I don't think some of the analogies hold...  Why wood framed houses are better than sticks and mud, might be a better comparison... or Concrete is better than Mud,  Or if you're only building a doghouse, you don't need concrete and steel.

While software development is not an engineering discipline in practice a lot of the time, it is more apt to compare to construction/building in general.

A lot of the reason for the polarization is that when you are working on a project for a company, you absolutely will favor one over another, and need to be able to defend and back up your decisions to the PHB types.  It is as much political as it is technical in a lot of cases.  IMHO, angular isn't as predictable or straight forward as you might think... There are a lot of times when I'm a user of an application (grubhub comes to mind) and state behaves very weirdly... more often than not, when I'm using apps with weird state issues, it's an angular app.

That's not to say you can't work around those kinds of issues, but it's working around the core of angular.  $scope.$apply(Async) is a huge code smell.  ng2 is better, but still has a lot of similar quirkiness.  Likewise I'm a proponent of React, though I feel too many people reach for either in cases where server rendering + enhancements would be better all around.  More over, I'd rather developers discover and start using sessionStorage/localStorage already to overcome a lot of the weird behaviors.

One other tip would be to use tag deployments to npm via travis-ci for your public modules.

It's best to think of web workers as something at the other end of a message queue, such as via an MQ server... it's faster and on the local machine, but still entirely separate wrt to the work being done.