https://github.com/thewhitetulip/Tasks-vue

Vue.JS is great to use!

Polymer's got the BEST router system however. It makes the URL choppable at the component level, not the app level. So you can literally throw in an external component and it can add it's OWN part of the overall URL. I don't know any other framework that can let an external component eat some of the URL if it needs to.

Even Cycle.js just has a few concepts and is even more flexible than React or Vue.

Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who tried to apply all the design patterns™

But I'm currently buying into the FP fad, haha

HTML is content. CSS is style. Javascript is shit.

Angular-cli because it provides a scaffold for getting started with the project and getting something up and running. The documentation feels pretty good. I like the example app they are building and the documentation format (they provide the full source code for the files right there in the documentation, no need to navigate to somewhere else).

[1] https://github.com/angular/angular-cli [2] https://angular.io/docs/ts/latest/

I'm not saying this is a good thing, but I started to read more in the frameworks repos after trying a few of them.

I think this is a barrier for most devs, but I think it made me better at coding.

The only client side JS library that doesn't seem to be a fad is jquery. Which now has backlash - maybe that's a sign of success in frontend dev land?

Current frameworks try to solve a higher level and most failed.

The minimal transform is usually trivial to implement by hand:

  var message = $('.widget__message'),
      title   = $('.widget__title'),
      button  = $('.widget__button');
  button.on('click', () => {
      $.get('/api/widget/1', response => {
          title.text(response.text);
          message.text(response.message);
      });
  });

You realize React solves a performance problem that it imposes on itself, due to immutability, right?

Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate.

remember appendChild() and removeChild() ? These are quite fast.

That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth.

The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.

Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.

>They simply handle events and remove/add/update the specific DOM nodes that are appropriate.

Don't bloody pretend you didn't.

I am specifically responding to this:

The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude."

Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.

You just use pure javascript/web standards html to create your application. All the people that I worked with that used it were really happy with it.

But I guess React will be big for the next years, because of FB.

Seriously though, if there has to be a certain "way" of using some technology I can't help but remember Code Complete, that you should always code into a language as opposed to coding in it.

I did Ember while Angular was "a thing".