hyperscript

es to making JavaScript-powered UIs like React's JSX or Angular's own templating approach or the templating systems in many other UI systems are obsolete. Modern webapps can use Mithril+Tachyons+JavaScript/TypeScript to write components in single files where all the code is just JavaScript/TypeScript. Such apps don't need to be partially written in either CSS and some non-standard variant of HTML that reimplements part of a programming language (badly). (Well, there may be a tiny bit of custom CSS needed on top of Tachyons, but very little.) Here is an example of a coding playground I wrote that way with several examples in it which use that approach: http://rawgit.com/pdfernhout/Twirlip7/master/src/ui/twirlip7... So, by writing UIs using HyperScript (plus a vdom library), you can potentially (with some work) replace a backend like Mithril with almost any other vdom or even a non-vdom solution. So, that is another way I mitigate this risk when I have a choice. Granted, I know many web developers grew up on tweaking HTML and love HTML-looking templates and so they love JSX or whatever and are happy to ignore how hard it is to refactor such non-code stuff in the middle of their applikcations or validate it (granted, some IDEs are getting better at that). But I came to web development from desktop and embedded development working with systems where you (usually) generated UIs directly from code (e.g. using Swing, Tk, wxWidgets, and so on). I like the idea that standard tools can help me refactor all the code I work on and detect many inconsistencies. Maybe a deeper issue for me is that with BSD+PATENTS Facebook is redefining what "open source" means in a way that is harmful to the open source community -- and also free software community as well like with Automattic using React on top of a GPLd WordPress. Which is why the Apache Foundation rejected the React license.

her framework including React. And then he repeats Sebastian Markbåge's, creator of React, tired complaint that Web Components can only consume string data. This is FUD, pure and simple. Web Components are Elements, and Elements are Objects with properties. Every Web Components framework relies on this for data-binding or setting "props". And... that's it. That's basically the extent of the critique. The author could have actually tried to compare React and Web Components and he would have seen that: 1. The component models are very similar, there are analogs for most lifecycle events. 2. Web Components don't prescribe state management or dataflow, and there are indeed functional, unidirectional, immutable (by convention), Web Components libraries and patterns out there. 3. Shadow DOM fixes nearly everything that css-modules address in a native and performant way. Web Components aren't a be-all-end-all standard. They are a few fixes to the platform that should have been there from the beginning, namely that you should be able to extend the HTML vocabulary (Custom Elements), you should be able to encapsulate some DOM and styling (Shadow DOM, which most browsers already had for their own UIs), and that you should be able to ship and parse _potential_ DOM (<template>). That's it. Everything else is either a library responsibility and/or TDB. Web Components are a foundation to make it easier to create frameworks, libraries, and an base-level interop story that answers some, but not all, critical, simple questions: How do I write a widget? : Extend HTMLElement How do I keep other scripts and styles from interfering with my widget's internals? : Put the internals in a ShadowRoot. How do I scope my own styles? : Put them in a ShadowRoot How do I instantiate my widget: Use a tag in markup, call createElement(), or call it's constructor. Anyone coming to the web platform as a new developer now doesn't have to sift though 100 frameworks and contradictory tutorials for such simple questions, the platform provides answers, as it should have from the beginning. [1]: See Hyperscript as a React-like example https://github.com/hyperhype/hyperscript