Offler

Adding 1,200 image components to a web app and never cleaning up the ones that aren't visible is a poor approach to building a mobile web application.

It doesn't matter what technology you use, it's a bad idea.

So he's basically tested the performance of a badly architected application.

You mean web components? I'm not sure it's possible to pass in anything other then strings as values via their attribute changed callback. They simply aren't as well designed and powerful as React components.

This might help explain where flux is useful http://briandipalma.github.io/flux-for-components/

I don't find the fact a brand new browser already supports legacy 'webkit-' prefixes a fun fact...

It might be a reference to Dart?

They can be enjoyable tests. I have learnt new things while doing some.

And Polymer.

Yes I think it depends on what level of complexity you are dealing with, Flux is an overhead for low complexity components. Once you get into higher complexity you need better abstractions and structure then what KO on it's own provides you.

In other words there is no one size fit all solution, but I think we all know that already.

Getters have been in JS since ES5 and can do what you just wrote. Obv Proxy is more powerful/has more traps.

> The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.

Sounds like two-way data binding went out the window then...

Very easily if they use ES6 modules and a package manager like jspm that understands ES6 modules. One line install, one line import.

> IMO they should be declarative, that is - in the HTML - but programmable, and that's the way things have been heading.

Sounds like React. WCs templates aren't programmable that's a DSL that is specific to Polymer.

I think the biggest problem with WCs is they are standardizing best practices from 2011/Angular early days. Things have moved on and mutable two-way state that binds to a stateful DOM is no longer state of the art.

I can drop a jQuery calendar into a React component with minimum fuss. I think the interoperability issue only comes with components from large frameworks.

SASS and LESS are CSS DSLs, you are doing limited programming with CSS, at that stage you may as well do programming in a Turing complete language like JS and reduce the number of tools in your tool chain.

3. By using meaningful values and separating side-effecting functions from pure ones, we can more easily reason about our program

I'm not sure how that's something that static typing provides, just seems like good functional programming/referential transparency.

Things are improving rapidly, depending on the scale you intend to build to mature solutions are available for you.

As it stands I don't see a better view layer solution then React, but I think you'd be best served learning it without using JSX so you can see exactly what it does. JSX tricks some people into thinking React is some sort of markup processor.

The older generation view solutions are usually string based templates with embedded DSLs to manipulate the resulting DOM. React divorces itself from the DOM totally and allows you to programatically generate and compose the view. Components and the separation from the DOM are React's great features.

Both Ember and Angular are trying to figure out how to integrate the React functional feel into their new versions and are taking notes. I just don't see them improving on React though at best they will copy.

He does mention React as being a library that hits some of the points, some of them are just your own personal UX/project decisions which a framework would have no say over.

You can send a pre rendered HTML shell with text content, when using server side rendering with something like React, quite quickly. I think this gives users a very nice experience especially compared to staring at a blank page!

I think people have different use cases that they aggregate under "web application". If you are building a desktop replacement application then I can see that initial load might not be such a big deal but if you are building a less complex application like the Twitter UI then server side rendering makes more sense. It's all context specific in the end. To hard to make general claims.

It's not really a post-React framework though, it has been designed at the same time as React was starting to take mind share so it's not clear if they have built something that responds to what React + Flux provide.

I've worked with developers who "just got it done", I would often spend months afterwards fixing up their messy code.

Today https://github.com/google/traceur-compiler

It sounds like they will add support for the same constructs as JS will have in ES7 https://github.com/lukehoban/ecmascript-asyncawait

I think a lot of FE devs aren't fully aware of npm scripts https://www.npmjs.org/doc/misc/npm-scripts.html - it's a handy way of calling commands just like you would in make. Quite a lot of the tasks that people use Grunt/Gulp for could be executed with it.

I would use npm scripts as the first way to execute build steps in a package and only fall back to Gulp when it's not powerful enough https://www.npmjs.org/doc/misc/npm-scripts.html

Don't rely too much on Grunt, only use Grunt/Gulp when npm scripts doesn't do the trick. npm scripts has the same direct command invocation that make has so no need for plugins.

It was basically create by people who didn't have much JS experience so that's why it looks like Java more then JS, in fact that's why it's Java and not node. You're right it could have been much simpler. It used to be much worse.

With traceur you can write in ES6 and transpile it to ES5 so I will imagine that ES6 will really take off over the next 2 years.

JavaScript is like Gravity on the client side, and with ES6/7 it's about to become a much nicer language too. You could never run Ruby natively, in a widespread manner, on the browser. With one language you can now build a complete stack and target all devices. That's quite big.