Frontend Architectures: The Next Generations - Mikael Brevik - NDC Oslo 2023
Vložit
- čas přidán 16. 06. 2023
- Contrary to popular belief, the frontend scene has actually been relatively stagnant for the longest time. On a macro level, we've largely followed the same patterns and architectures with only minor variations for the past 6-7 years. This is about to change.
After a period of stability, we see a significant shift in how we approach and solve problems. And what types of problems we solve.
Let's go through some of the biggest and most important changes to architecture, tooling, and patterns in frontend that are happening today and tomorrow. Let's also take a technical deep dive into how they actually work so we can gain a clear understanding of when to use them and for what problems. We'll look at different solutions such as Qwik, Astro, Edge Functions, Solid.js, and many more.
Check out our new channel:
NDC Clips:
@ndcclips
Check out more of our featured speakers and talks at
ndcconferences.com/
ndcoslo.com/ - Věda a technologie
Nice talk, one more item for meta framework list, Angular -> Analog
Wish there are actual table of data backing up the claims at the tail end of the talk
I wish Mikael would have explained better the benefits of the architectures described. To me, it just sounded like "this is the new stuff and the old stuff is very old" without persuading me why I should consider things like adding server roundtrips that would have been avoided with SPA.
Because there are none. It's just trying to come back to mvc architecture but while using javascript both on be and fe. While in old days u had one mvc app build in some non js language without roundtrips from db to be app to frontend. Hydration is trying to fix problem created by spa, but making it slower in the end (as long as u dont use on edge functions), for first users as long as data doesn't change.
This isn't about Gen 0 (Igor Minar) web apps where every interaction is a form submission.
Hosting a web application there is no control over the connection quality to the client or the computational capacity of the client. On the other hand the computational capacity of the web application host can be controlled.
Gen 3: What can be done on the server will be done on the server; what has to be done on the client will be done on the client.
Use server resources up front so that the client needs to do less (using less JavaScript).
Remix, TanStack-bling and to some extent RSCs enable server-client collaboration implicitly without requiring an explicit REST, GraphQL, tRPC, interface.
@@peerreynders1824 Thanks! That is actually helpful, and I can learn from it.
Still seems wrong to say this is the "next generation" and synonymous with progress. The server-based approaches feel more like a way of creating web apps that will be better in some situations like you've described (e.g. limited computational capacity on client), but not all. And I retain my bias for the opposite approach: "What can be done on the client will be done on the client; what has to be done on the server will be done on the server." Because I see all kinds of wasted compute/storage on people's devices, and all kinds of latency/scaling/fault tolerance/compute costs on servers. I'll stop short of saying that SPA, edge computing, offline-first, etc. is The One Way. Different solutions for different problems, is all.
@@seespacelabs6077
In 2022 the Thoughtworks Technology Radar issued a hold on SPA by default, twice.
Typically in ecommerce SPA is the wrong choice; e.g. EBay developed Marko for that reason back in 2014 as a server first framework and it is now considered a Gen 3 framework.
Making the world’s fastest website, and other mistakes
How can performance improve conversion?
@@seespacelabs6077 Precisely - we seem to be conflating that all web page experiences must be served in the same manner - your heavy line-of-business SPA frontend has a much different set of requirements than an eCommerce site. Working in the SPA world (with heavy emphasis on the Application) I see SSR as the antithesis of everything that's been distilled and refined over the last 15 years. However, I can see there are advantages of serving pages lightly and quickly in the eCommerce space. My question is then, what is the point of all that functionality in the browser if we're just using it as the thinnest of thin clients and serving up raw html?
The more they encapsulate the farther from the truth.
React will never be.
Speak clean and you will survive.
It's called a POSTback and people already did that with forms with JQuery. It's not new, it's just new dev's reinventing old things.
What about HTMX?
Any relation to the Diablo 2 Brevik??
it sounds like not that much happened on the frontend during last years, just a couple of new frameworks and that's it
the future will be web component