Technology Based on Proprietary Ideas vs Based on Web Standards

Paul Lewis - Custom Web Shadow Elements, or Whatever…

Paul Lewis’s musings on the tensions and support between proprietary ideas/standards and web standards - in this case React vs. Web Components.

Keeping in mind that Google heavily influences … eh, contributes to the Web Standards while (generally) Facebook doesn’t bother.

Modern Web Development (2016-Feb-03)

2 Likes

From ‘A different Kind of War’:

https://twitter.com/jensimmons/status/1089611138176860161

I’m all for bootstrappers and small teams - and why I think Elixir and Phoenix are so appealing :smiley: Erlang/Elixir lets you scale relatively easily and Phoenix (thanks to things live LiveView) helps drop the need for bloated/complex things like React. A single person can go a long way using Elixir and Phoenix :003:

4 Likes

i think the points raised are fair enough and i agree that this is some kind of war. But i think it’s to shallow to think that there is a right side on this. I like the experiment Richard Feldman does on this talk explaining the origin of css:

html, js, css are not the proper way to built a UI for applications. web went from static html/articles delivery to an application delivery platform and the way we think web apps now is a issue. personally i don’t expect that the solution gonna come from neither of those companies.

1 Like

I not sure that’s the right way of looking at it.

The web is successful exactly because of the way it works - even if it is less than ideal for “UIs”.

For example SOAP was trying to ignore the characteristics of the web and despite the vendor pressure to push it through, it lost out to REST which embraced the constraints of the web. Whether or not REST will lose out to GraphQL (which again tries to ignore the web by being transport agnostic) in the long run remains to be seen.

Similarly trying to ignore the characteristics of the web (especially the fallacies of distributed computing) and by extension failing to play to the strengths of the browser platform to establish some kind of “ideal UI application development ecosystem” could be headed for disaster.


Dear Developer, The Web Isn’t About You


Webstock ‘18: Jeremy Keith - Taking Back The Web

3 Likes

I guess I was not clear or I misunderstood the main subject here.
When we talk about web standards and a war between Facebook and Google in the way they choose to influence how software development is done - we are talking about development.
When we talk about different scenarios of web usage and user experience and diversity of ways to experience content using internet - we are talking about users an UX.

As i understood, we were talking about development, so the way those stuffs impact the way we develop is the matter here. Saying that we should stick to html, css and js as the way to write web application is like saying people should develop in asm because people uses computer, and computer works because of asm, so we shoud stick to it.

So being explicit about the initial subject and my proper opinion on it. I don’t think that this gonna make a difference, because i think the end result gonna be new standards that won’t be aimed to be human writeable/readable, but to be as resource economic as possible(smaller payloads, smaller loading times, smaller rendering times), and in the same way wasm relates to js now we gonna see equivalents to html and css.

“Web Standards” has always been used to refer to specifications from independent organizations like the W3C for technologies and protocols used on the web.

Something like React is tool based on a proprietary idea (in this case from Facebook) of what components in a web page should be like - while it may have gone mainstream in isn’t considered a “Web Standard”.

Web Components on the other hand is a Web Standard based on parts of the HTML 5 living standard particularly the template element, HTML Custom Elements, and Shadow DOM.

(Even the WebAssembly JavaScript Interface is a standard/specification).

Saying that we should stick to html, css and js as the way to write web application is like saying people should develop in asm because people uses computer, and computer works because of asm, so we should stick to it.

That is a commonly held attitude but it is comparing apples with oranges.

Any browser (with capabilities governed by the Web Standards) based application is a distributed application. The web is a particular distribution infrastructure and platform with certain constraints and limitations, governed by physics and those Web Standards.

(Whenever distributed applications come up, I feel compelled to bring up Convenience Over Correctness (2008))

1 Like

I think you skipped that part. I understand and agree with all that. I just don’t think people need to write on those standards.

And here is where you miss the point entirely, you’re right react is tool and not a standard because it’s supposed to be tool that gonna be used by developer. The whole point of a tool is to abstract away a concept that is not necessary to understand fulfill a job.
Ok so what is the matter if react is proprietary or not, it’s just a tool. We don’t discuss that people uses a proprietary editor or a open source/free software(just choose the philosophy you want here) one. The end result of react, or elm, or cljs/reagent, reasonml, typescript or whatever else you use to write your application still gonna be html, js(or wasm) and css no matter how the developer wrote it.

These standards exist to define and shape the capabilities that are at everyone’s disposal.

The whole point of a tool is to abstract away a concept that is not necessary to understand fulfill a job.

Not all abstractions are created equal.

Many of them aren’t even useful.

In particular React’s abstraction is entirely based on JavaScript, in effect isolating the developer from the browser’s other powerful capabilities of parsing and processing server delivered HTML and CSS.

In fact the browser’s priorities are

  1. Parsing and flowing the server delivered HTML markup
  2. Parsing the server delivered CSS and laying out the markup
  3. Parsing the JavaScript and initializing it.

i.e. JavaScript is the very last of it’s worries and yet JavaScript frameworks are acting as if JavaScript is “king of the hill” inside the browser.

The order of these priorites is based on the web browser’s fault tolerance model:

  • Content is the foundation
  • Markup is an enhancement
  • Visual design is an enhancement
  • Interaction is an enhancement
  • The network is an enhancement (Service Worker API / Offline First)

(Note that minimal server-interactivity is guaranteed with just markup via forms.)

So to get around the isolation of React’s abstractions it has become necessary to introduce runtime JavaScript-based SSR on the server in order to take advantage of the browser’s strengths - parsing and processing of server delivered HTML and CSS.

So by abstracting “the gross” of the browser away, React has created additional complexity elsewhere, in the process constraining how React applications can be constructed in order to be able to use SSR and for the most part dictating that JavaScript has to be used on the server side for rendering.

Meanwhile React’s abstraction relies for the most part on the presence of a VDOM which at first seemed like a brilliant move (some disagree) but the VDOM will likely become a hinderence in the future.

Furthermore the SPA model (and Elm is in this camp as well) is just one of a whole spectrum of ways to construct web applications.

Flash was successful for a time to some degree because it made the browser irrelevant for flash developers.

But is Flash (Java Applets, ActiveX, Silverlight) relevant now? HTML, CSS, ES and the browsers survived them all - and meanwhile the Web Standards have evolved with them.

Similarly the SPA model with it’s server-side JavaScript SSR may simply become a blip in the history of the web.

To my mind Svelte 3 is pointing in the right direction but as such is still flawed as it is an entirely JavaScript focused technology. The logical extension is a tool that outputs not just JavaScript but also platform independent templates for (initial) server rendered HTML and the supporting CSS.

However that requires a team that is much larger than the Svelte team and will likely result in a suite of tools that will rival Eclipse and Visual Studio (not Visual Studio Code but the commercial product) ecosystem. Whether and when we’ll arrive at that point is anybody’s guess.

But even then developers will still complain - for example, if the tool enforces accessibility standards - why they have to concern themselves with all this other nonsense - they just want to built their application and be done with it.

It’s simple enough to avoid the browser - stick to native apps.

However everybody wants to leverage the universal reach of the web and browsers (HTML/CSS/JS/WebAssembly) are an integral part of that reach, so they get to dictate the terms.

Sure, Browsers are D**ks (in the words of Jake Archibald) but the Web Standards lets you take advantage of them to maximal effect - for the most part.

3 Likes