YUI is an example of a key problem w/ corp stewardship; Angular, Polymer, React all OK though?
HTML Imports in trouble as Mozilla doesn’t want to implement; Custom Elements OK even though Chrome is the only implementation?
Overall, Brian mentions four specifications, and crosses off three. Why not all four?
My take is that this talk lumps React in with others based on when it was introduced; but that it is fundamentally different from, say Angular.js as Angular.js is from jQuery. Compared to the alternatives, react is more imperative, and is based on a virtual DOM. It also can run in both the server and the client.
I have my own page on which I would suggest that you view source: calendar-demo (Update: that site is down, try this static snapshot). Use the left and right arrow buttons to go to the previous and next months. Viewing source reveals that the page is delivered pre-rendered, and only after the content is delivered are script libraries loaded. Traversing to the next and previous months are pretty snappy despite the fact that there has been no optimization: in particular, there are no anticipatory prefetches. Nor is data retained should you go back to a previous month. Neither of these changes would be hard to implement.
Source is available in svn. Check it out, do a bundle update to get the dependencies, run rake if you want to run a few tests, and run rackup to start a local server.
I must say that being able to define a component with all of the rendering, client, and server logic in one place is very appealing to me.
Brian suggests authoring source in ES6, and targeting ES5. My preference would be to work towards building a language that is to ES6 as CoffeeScript is to ES5. At the moment, my experimentation along those lines is happening in Ruby2JS.
React Native looks worth watching. Perhaps as my calendar is using flexbox, I will be able to quickly build an Android or IOS equivalent.
I get a 403 Forbidden trying to access your calendar-demo.
Oh awesome! Yes this talk is a big work-in-progress as the story unfolds. Key points where indeed key: Angular, Polymer and React all should be regarded as somewhat risky. YUI did have a good run but, in contrast, Dojo is still running. Facebook has stated to me that they want to see community stewardship for React, so that is positive.
HTML Imports: I jive with Mozilla on this one. Service Worker and ES6 Modules APIs are on the immediate horizon which means an HTML Imports could be be a library, even in its own Custom Element. mind blown
Why do I like Custom Elements? Well, it is a very tiny polyfill so it works everywhere that Angular Directives, React Components, Ember Components and other what-have-you things do, for less payload cost. The concept is good, and that code has the most likely path to standardization. That is what I like about 'em. YMMV.
I def don’t lump Custom Elements in with React. Now that said, a Virtual DOM is not a technology incapable of dissolving into the web platform. I kind of expect it (or something like it) will find its way into browsers. It wouldn’t be that much work to bolt a vdom on the Custom Element lifecycle, for someone else. ;)
Other languages: yes pls! Key suggestion there: distribute compiled ES5 source, ideally on npm, so I don’t have to learn your build pipeline or module system.
Last thought/spoiler alert: React Native is totally awesome. =)
I utilize a program to enter genealogical information. This program is a standalone that keeps running on my PC (this would be a non-web part). Part of the usefulness of this program is to permit me to make a guide utilizing Google maps (which would be a web data framework).
Utilize the left and right bolt catches to go to the past and one months from now. Seeing source uncovers that the page is conveyed pre-rendered, and simply after the substance is conveyed are script libraries stacked.