Moonchild, the lead developer of the Pale Moon browser writes:
"Dear Web Developer(s),
While, as a software developer ourselves, we understand very well that new features are exciting to use and integrate into your work, we ask that you please consider not adopting Google WebComponents in your designs. This is especially important if you are a web developer creating frameworks for websites to use.
With Google WebComponents here we mean the use of CustomElements and Shadow DOM, especially when used in combination, and in dynamically created document structures (e.g. using module loading/unloading and/or slotted elements).Why is this important?
For several reasons, but primarily because it completely goes against the traditional structure of the web being an open and accessible place that isn't inherently locked down to opaque structures or a single client. WebComponents used "in full" (i.e. dynamically) inherently creates complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers (primarily Google Chrome).
One could even say that this is setting the web up for becoming fully content-controlled."
https://about.google/: "Our mission is to organize the world's information and make it universally accessible and useful"
Useful to... whom?
(Score: 0) by Anonymous Coward on Friday March 20 2020, @09:40PM (4 children)
Things like Single Page Applications (SPA) along with tools like Angular are the way of the future. No one wants a shitty, slow, server-side generated bunch of woo-tang that is reloaded every time you want some small data source. Like it or not, the old way is mostly out for anything that is data driven.
Static pages still make sense. For static content. Like diary entries. But dynamic content, no, it's SPA and progressive web applications.
(Score: 3, Interesting) by Anonymous Coward on Friday March 20 2020, @10:30PM
Angular and "SPA all the things" was the wave of the previous decade.
Fortunately, I'm starting to see more people talking about server-side rendering, combined with JS loading the data-driven portions. That means the first request can contains a full page again, and the page updates can be served as HTML fragments, rather than JSON parsed and converted to HTML at the client side.
Static pages do still make sense, and hopefully this decade we'll not see so many static pages delivered as SPAs.
(Score: 4, Insightful) by sjames on Saturday March 21 2020, @04:56AM
And made for XYZ browser only is also so very mod '90s. Remember the clueless "e-commerce" sites that wouldn't even display if you weren't using IE?
You wanna do SPA? Fine, stick to actual standards and interoperate.
(Score: 0) by Anonymous Coward on Saturday March 21 2020, @09:50PM (1 child)
This isn't an either-or choice. It's perfectly possible to make a web app that works just fine without Javascript or anything fancy while using it to avoid reloading and provide a better experience if it's available.
(Score: 2) by Pino P on Monday March 23 2020, @03:58PM
Provided the budget allows both. It appears that in many cases, the budget for a minimum viable product (MVP) allows for only a fully server-side rendered front end (with occasional progressive enhancement) or only a single-page front end, not both. And the following thought experiment may explain why budget-crunched web app developers end up choosing the single-page architecture over a noscript-friendly architecture:
I'd like to see how a web-based text chat client, as a front end to IRC or a replacement for Discord or Slack, could be made to work efficiently without client-side script.