Escaping the SPA rabbit hole with modern Rails – Jorge Manrubia – Medium

It’s a good point about “tooling” adding complexity elsewhere. My experience with React, especially using UI component libraries like React Material was an awkward amount of coupling between the responsive/Javascript elements, state, and the UI/View elements. I’d like a UI library to take the minimal amount of effort to build things. The idea being that if the perceptibly easiest path is copy-paste driven development using something like MUI or Bootstrap - we’d should at least make the workflow maintainable because it will be done regardless of technical merits. Especially as the front-end Javascript world is a large source of new developers. If I build an app using a UI library and the ecosystem inevitably shifts, do I have to wait for my UI library developers to update their components, then hope that the overindulgent abstraction doesn’t necessitate a heavy change cost?

Seems to me the solution is somewhere in the vague idea of a good separation between responsiveness, state management, and UI/presentation.

So it’s interesting to see Google using Web Components as wrappers for their own Material design libraries instead of re-implementing the whole thing for every Javascript framework. Salesforce is also making similar moves to web components (albeit in typical Salesforce fashion by coupling everything to their infrastructure). From a naive perspective it looks like web standards are just integrating what we wanted from React/Vue anyway. How soon before the value of React and Vue is overshadowed by the simplicity of just using vanilla Javascript and standards like web components?


I don’t think it’s going to work that way. I think it’s more along the the lines of “You might not need React/Vue”.

  • Edge doesn’t even support custom elements yet.
  • While web components aren’t especially hard, I don’t think they’re easy either, the browser’s web-api is rarely easy. Hence why lit-html exists.
  • Even on the lit-html level using web components naively won’t automatically yield positive results. They are still JavaScript based so standalone (rather than cooperative with the document) implementation where a component is responsible for putting the first paint on the screen will still be less than optimal. What’s worse, certain implementation styles won’t work well with some frameworks especially if their SSR technology is used.

It really comes down to knowing what the tradeoffs of each tool in question are and what tradeoffs provide the most value in any particular situation. For example: “The secret of the VDOM isn’t about performance, it’s about simplicity”. That simplicity comes at a cost of running diffs on the client device and on some clients that cost is inconsequential - on others, not so much. If you only have some interactivity a VDOM might be overkill. So Polymer’s PWA starter kit could be enough (though apparently going full Redux is OK; :man_shrugging:).

I’d like a UI library to take the minimal amount of effort to build things.

I think one of the issues is the perspective of native WYSIWYG UI design tools. Native UIs are collocated with the functionality they interact with so seeing the widgets as a representation of the internal component seems natural. SPA’s try to force that kind of environment on the browser by migrating application functionality to the client and then manipulating document fragments as part of a visual component - entirely in JavaScript. But browsers are optimized to deal with pages in layers: markup/visual design/interaction. Now tools could transform a component design view to a page implementation but what kind of design time information do you have to provide to be able to generate semantic markup (in most cases tools don’t bother)?

So while UX design principles apply to both native and web UIs, the design process for a web application page seems radically different to a native UI due the functional characteristics of a browser (and the web in general).

Seems to me the solution is somewhere in the vague idea of a good separation between responsiveness, state management, and UI/presentation.

There is no one solution. Each problem has a different optimal solution. In an effort to adopt the one approach that covers the most scenarios a large part of the industry has landed on SPAs. But flexibility comes at a complexity cost (among other tradeoffs) and under-utilized flexibility is a waste. There is a full spectrum of rendering options but there is always the temptation to use whatever seems the most flexible - “just in case”.

1 Like

Well Edge is swapping to use the chromium backend soon, so… that will soon be fixed. ^.^


Progressive Performance (Chrome Dev Summit 2016)

An entertaining 2016 talk about the constraints that mobile devices operate under to “deliver the web experience”. They are fighting “the laws of physics” every step of the way.

Improve a phone’s performance - by running it on an ice pack.

The 2018 version of the talk isn’t as entertaining but explains why matters aren’t going to improve much in the near future - largely because the performance of the average phone isn’t actually increasing that much due to the economics of silicon foundries:

The New Mobile Reality - Alex Russell (Google)