It is no secret that the past 2 years have seen the beginnings of a fairly dramatic change in frontend web technology. I write about these topics r...
For further actions, you may consider blocking this person and/or reporting abuse
I´m watching this for a very long time now! The World Wide Web - as it was initially created - has some serious design issues. Many concepts were logical and useful - at a time when people were using acoustic couplers and 56k modems. But the concepts have never been really powerful. Identifiers in HTML and CSS have always a global scope, limiting their use to small projects. The whole system was intended to present scientific documents over the newly invented "internet", but not for what it is used today.
But times have changed. People watch Netflix on their mobile phone, so bandwidth should not be our greatest issue. And browsers are increadibly fast - even on a raspberry pi. So, what´s the problem?
We are still using HTML like Tim Berners Lee did. Libraries like React or Tailwind are just solutions to problems, that should not exists. With every new tool and solution, the complexity rises - making the whole system less useable. Now we have partial hydration and islands - it will not take long until we see a solution for the problems, that are caused by this technologies.
For me, there are only two possible ways to go:
a) run your app on the server and use HTML and CSS only as a vehicle only. This is the way, wordpress works. It widely ignores the all the web standards and creates a world of it´s own.
b) run your app in the browser and play on the DOM directly without any HTML. This is the way, libraries like DML or VanJS go, even Svelte goes that way - under the hood. This approach is fast - as long as you do not need to pull a bigpack of tools before you start rendering your page. VanJS provides all you need to build reactive apps with an overhead of less than 1 KB. There is absolutely no need for hydration. You should try to measure rendering time of the VanJS homepage - I suppose, it will be far less than 1 ms. Even pages created with DML - that is not optimized for size in the current version - feel more responsive than many other pages.
I´m sure that we could get much better results if we do not waste more time using technologies from the past. Javascript and the HTML DOM API provide enough power that we could completely skip HTML and do something better. VanJS shows, that it is possible to build a perfectly usable system, I´m sure we could build even more efficient tools that do not bloat the whole system. But this should be built on a proper foundation, not on concepts from the past.
It's nice that that's your experience but it's far from universal.
The Performance Inequality Gap, 2023
Also related Now THAT’S What I Call Service Worker!—in which Jeremy Wagner relates how he had to carefully consider the constraints of the web solution for one of his client's in order to maximize the reach to (potential) customers.
And people make fun of some of the arcane technologies …
… that some of the tech giants are (still) using.
But what is overlooked is that some of the developers there are so well compensated because developer experience isn't a primary objective for the products they work on.
What is prioritized is reaching every last customer and minimize the probability of having them balk just because the wireless network is throwing a tantrum because some bad weather is moving in.
Not many Raspberry Pis run on a battery while powering a wireless radio.
“Mobile reset everything”
Nobody is disputing that CSR can be pretty fast under ideal conditions. The issue is that conditions aren't ideal everywhere and everytime, not even in most places and most of the time.
So partial hydration, islands, server components and resumability are solutions that help claw back some of that edge that corporations with expensive engineering teams have who can approach the ideal set by the instantaneously served static page (browsers process HTML/CSS much faster than JS).
Like what? It took the web 34 years to get where it is now. Sure there is some historical baggage most notably the single, fat core mindset of JS (but the same could be said of Object Oriented Programming). Wireless networking will always be constrained by the laws of physics and client-server connections will always be subject to the Fallacies of Distributed Computing.
5G may only benefit a minority of users but could be further from its ideal than previous technologies; it has a shorter range and is more easily blocked (e.g. glass and foliage).
You can have an LTE connection and still only get 10-100kbps (spec is 100Mbps; Netflix recommends 3Mbps for SD/480p and 5Mbps for HD/720p).
Wordpress is not the gold standard for HTML/CSS; an immediately served static page is. While Wordpress can generate static pages certain performance aspects are traded off for affordances for CMS users.
And right there you are leaving a lot of performance on the table. Browsers can turn HTML a lot faster into DOM than JS can create it from scratch. And more to the point it will usually do so in a separate thread (perhaps on a different core). So not only is there less JS to run (initially) but more of everything happens in parallel.
You seem to perceive a very narrow slice of the web's value. It serves a whole spectrum of application holotypes all of which have very different needs and benefit from very different capabilities.
This starts on one end which aims to maximize content density for the network payload going to the other end for use cases like Figma.
Great absolutely great response plus sharing references is absolutely incredible
I am very interested in seeing if the hybrid has legs. I agree the platform is getting used beyond its original intention and people are working for new standards. But yeah backwards compatibility makes the Web great and well,.. your image. With SolidJS we've built arguably the smallest(when you include component code size) and fastest client framework but I think there is more here if we keep going.
SolidJS is an UI framework, and maybe it solves the problems of an UI-designer in the most brilliant way. But what about the rest of an application? Do the tools and methods SolidJS provides help us, to build better applilcations? I think, the whole picture should contain more than HTML and CSS.
There are different application holotypes, and I´m pretty sure, even static HTML will have a place on the web for a long time. But people start to bring more and more business logic to the client side (see serverless-application), just because they can. Or because it makes their task easier, their life simpler or whatever. There may be many good reasons.
The "hybrid´s" I have seen have been running pretty fast, at least fast enough for me and my clients, even on very slow connections. They did not need to load bulky frameworks, often all they needed to fetch was 30-50kB of Javascript on initial page load, no HTML and only some small CSS files. Shure, this is not the whole application, but loading other parts of the code on demand is not a miracle today.
If you want to build your own "google docs", you would not want your client to wait until the application is completely loaded. So, you have to think how to overcome the bottlenecks. But this is not a question of the UI only... It´s a question of a good software design.
We have seen some improvements in transportation over the last years, and I suppose, a Tesla will not run on oats too...
For some reason lm really really having understanding this question :(
Is a site considered interactive if clicking a button works in the sense it does a slower full-page navigation(server round trip) where it otherwise would have done stuff in the browser only?
According to INP an interaction is:
However the measured latency is based on
So a no-JS page navigating to the next page but delayed by an abysmal server latency could have hypothetically a perfect INP score while a page blocking its next frame because of a high latency fragment/API server could have a poor INP score; both provide a similar, terrible user experience.
Hmm feels like it's a metric designed to favor MPA's 😂
INP is only one of the Core Web Vitals.
But like it or not, serving a static page with minimum latency even under the worst network conditions is the gold standard. Local-first is all well and good but it has to fit the use case where the users are willing to accept the inevitable drawbacks.
Progressive Enhancement means authoring all interactions back to anchor links or form posts. Which means that they work without JavaScript loaded. However, if JavaScript is expected for the experience do you consider this interaction before JavaScript has loaded as being interactive.
Picture you have a collapsible summary section on an item for sale. If you click the collapse button before the JS loads in a Progressively Enhanced application it would reload the whole page to render it with the section collapsed.
Whereas with JS you'd just hide the section in the client without even going back to the server. The difference between clicking early on a slow network is a substantial difference as now you have to wait for the page to load again, and as it is most likely that the JS hasn't loaded on a slow network it really is insult to injury. If there is no visual affordance its hard to say that these experiences are equivalent even though to the user they appear to be.
I'm not speaking against Progressive Enhancement.. I think it is good for graceful degradation, so that the site works when things do go wrong. But its hard to consider it as part of your load time metrics when the result can be so much worse.
This too
Will Resumable Solutions ever embrace explicitly calling out which parts of the view render in different locations?
Try to explain this to your grandma...
Great article 🚀
Framing server components as "Islands + SPA navigation" is what helped me quickly wrap my head around the architecture (my reflection of this). However, I've not delved under the hood and it's interesting to hear that RSC invented their own serialization format.
I'm curious what you think of Astro's View Transitions API that seems to have island state persistence on navigation and if that's enough to label Astro a Server Component framework, rather than an Islands framework. I know SolidStart had been experimenting with Server Components long before Astro introduced this, but now with the SolidStart/Astro collaboration, will SolidStart be leveraging this new API under the hood?
Also, what are your thoughts on framework agnostic islands like
is-landfrom the 11ty team? I've only just started playing with it, but it very much feels like Astro islands that you can drop in anywhere since it's just a web component.I was trying to say it wasn't in the Server Component section. Astro can persist elements but atleast the solution today detaches and replaces elements which can have side effects, and Astro hasn't solved for global state. So large part of why I wrote this article is to emphasize that even Islands with View Transitions as we see today aren't equivalent to Server Components. We learned that through experimentation on SolidStart where we had very similar Islands persistence and then realized the shortcomings.
The Astro collaboration was just for deployment. Everything rendering was Solid handled. Although we are looking at Nitro now as our underlying layer. Check out my upcoming Vite talk for more details.
As for is-land and 11ty, I mean Web Components make decent Islands.. but coordinating state really is where the problem is heading if we want to make more application like experiences out of this which is why Server Components/Resumability is a natural extension. I care about the App side more than the Site side but any Islands solution is perfectly good for sites.
Nitro is now under consideration.
On the topic of Astro view transitions stuff, would you say astro apps that use it are
I'm genuinely confused about the architecture.
Astro is just hitting the ground running. They want to be ready when View Transitions become available for cross page navigations.
Astro covers the MPA to µSPA (just enough islands to cover the interactivity for a single capability) range.
It enables an architecture that was considered an anti-pattern in 2015 when the document vs. application web dichotomy was taken for granted.
If you haven't read it yet:
Patterns for Building JavaScript Websites in 2022
Ryan Carniato for This is Learning ・ Jun 8 '22
I'd say MPAs that happen to not unload the page in the browser on navigation, plus some extra bonuses like persisting elements. They don't really behave the way SPAs work.
Personally, I making this: github.com/javaScriptKampala/z-js and I think all we need are specialized frameworks which give clear use case scenarios, and we follow the old pick the right tool for the right job, problem is frameworks are doing too much, where always tradeoffs have to be made instead!
"a resumable solution on its own would load the same code on navigation as an SPA"
I still don't see why this is a problem. Instant initial load, instant subsequent navigation, as long as network speed isn't awful.