JavaScript vs the Web Stack

I want a Gonzo!

For the Gonzo exploratory engineering project I’ve been working on the backend receiving data as well as the web interface where said data can be viewed. Compared with the other parts of this project which were replacing the system app on Firefox OS with a camera and 3D printing enclosures for a new kind of device I definitely got the most straightforward one. However, since we didn’t have enough unknowns on this project I’ve jumped on every emerging web fad and gone down every rabbit hole I’ve encountered on my way. It’s been great fun and it’s made me think a lot about where Web UI is heading.

Engineers at Facebook have been killing it on the web development front lately, releasing project after project after project. Facebook seems to have this extremely pragmatic approach to web development where what works today trumps everything. Old best practices of splitting websites into Javascript, HTML and CSS or into models, views and controllers are ignored and promises of a future with Web Components aren’t taken into account either!

What seems to be emerging in the “Facebook stack” is a website made entirely with JavaScript.
First, interaction with HTML is replaced with a virtual dom. As David Nolen of Om and ClojureScript said when React was released: “If you treat the browser as a remote rendering engine and stop treating it as a place to query and store crap, everything gets faster.” With React the HTML is stripped of its responsibility for state and is left as a rendering target.
Second, with experiments such as react-tween-state and react-gss we move even further from the native browser technologies taking both layout and animation out of CSS, leaving that too as a stateless rendering target. React-tween-state aims to replace CSS defined animations with animation parameters calculated in javascript. It then uses CSS only for explicit positioning using those parameters. GSS (GridStyleSheets) uses a javascript engine to enable new, more declarative layout options that it calculates into standard CSS layouts on the fly. When making a website where JavaScript manages both state and style the browser technologies we ultimately render to feels very unnatural and forced. They’re only there because of the reach that browsers give.

However cumbersome this all seems, the results speak for themselves. I’ve yet to hear someone make the case for a stateful DOM after being introduced to the virtual DOM paradigm. Similarly, early experiments with replacing CSS animations with JavaScript (I’m especially thinking about Famo.us) achieve visually amazing results unlike anything we’ve seen on the web so far. In other words, using JavaScript for everything seems to give both a better development experience and better end results.

Extrapolating on where this path could lead us we might replace the entire rendering target with something more optimizable - I’m thinking of webGL, the javascript bindings to openGL. On one hand this makes me sad. When Mitchell Baker, Chairwoman of Mozilla defined openness, the ability to inspect and learn from other products made with the web stack was an important pillar. Will we lose much of that if we replace the DOM? On the other hand I’m kinda excited. While I’m no expert, openGL seems to be a performant rendering target on all mobile platforms, and companies such as Outracks shows great potential for finally making proper cross platform apps. You know, the big promise of the web in the first place.

The Second Coming of Artificial Intelligence

Artificial Intelligence is eating the world, but how can we use this new power for good (and profit)? And should we be worried about the killer robots?

Read More

Software Security in the Agile Way

Published on February 17, 2017