Deciding on the approaches and tools to use to build on web these days can be a challenging prospect. There are many different options available an...
For further actions, you may consider blocking this person and/or reporting abuse
Thank You for making this publicly available.
"Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it."
SPA by default - Hold.
It feels like this article is providing some "trade-off analysis" criteria that earlier were either implied or have been missing entirely.
In 2017 PPK got into some hot water with his perspective on "what is a web developer"—but I think it would be highly beneficial for any "web developer" to fully understand Rendering Patterns (formerly Rendering on the Web) and this article.
Partially to understand where one's skill set actually fits in (hopefully avoiding wielding a golden hammer) and why a diverse ecosystem of libraries and frameworks is necessary to offer approaches that are better optimized for varying sets of solution constraints.
Again, thank you for broadening web development education in this fashion.
Thanks for the write-up.
Just to tie what you saying to jobs and learning. It seems a bit sad to me that it is becoming more niche to make a particular type of "javascript website". If you want a particular type of job, which do you choose?
Right now, many people choose to learn a UI framework (React is top I guess) and a related application framework (maybe Next as number 1 for React), and that covers more of the large-scale and corporate side of the spectrum of javascript websites (storefront, social network, immersive). And I guess this is where you can more reliably find a job, in terms of number of positions and salary.
While SSGs and newer frameworks like Astro cover the other side of the spectrum (Portfolio, content). These types of "javascript websites" might fall into the freelancer, or agency worker, or small business type of jobs.
Then, there is a middle-ground that is less distinct. For example, smaller storefronts can built in a wider range of tech because the demands are lower.
Does that sound like a fair characterization of how the landscape is relating it to jobs?
As for learning, I find it hard to pick winners for next wave of established frameworks in this space. So, I just retreat to the backend or more predictable shores! I think in the long-run we all gain in innovation and getting a faster web, but in the shortrun it leds to feelings of insecurity and uncertainty for devs.
What do you think in this regard?
Mostly. But its why there is a rush to the center. The problem is everyone is just choosing React whether its good for them or not. You'd hope Astro/Marko/Qwik would be getting the Lions share but they aren't. SSGs in React etc..I focus a lot on the future and the right tool for the job but I don't think that reflects in the job market. There we have companies having retired legacy all trying to use React.
It's a strange one. If all you have is a hammer, you treat everything as a nail! 😀 Let's hope that things pivot soon.
What‘s kinda sad is that in these small business type of jobs that you are describing, the industry standard still seems to be WordPress which most small agencies would rely on even if many sites could benefit a lot from using Qwik, Astro or 11ty with some headless CMS.
For me it seems that it still will take a while till there will be a true shift. What do you think about that?
I think some established agencies are WordPress shops. It depends on how progressive they are, and what customers ask for, if they shift. I think freelancers have more freedom to choose.
I guess a lot of the resistance comes from people wanting to choose a safe bet. Some folks dont want to learn 4 different frameworks for delivering the best type of website. This leds to the same choices being repeated. Really, they should focus on the suitable niche, rather than accept projects where WordPress is not the best fit.
You don't really need JavaScript in title. You could also include Jekyll, Hugo, and newer ssr like Laravel + http caching as an option
Those technologies are primarily Gen 0 technologies despite the fact that they are in modern use.
Given the various classifications given here Gen 3 solutions are also MPAs but for the time being they will be heavily reliant on server or edge side JavaScript especially if they are aiming for "resumability" until such point where code generation can replace the server side code with something else.
MPA, "Server-routed multi-code entry site experience", doesn't imply pre-2010 style dynamic server side rendering of (just) HTML.
Laravel and HTTP caching are new?
I am thinking of the turbo/hotwire/livewire/liveview family of ssr. I don't know how old livewire is.
I would in concept describe those as server rendered SPAs requiring a continuous high quality, high bandwidth, low latency connection. As per navigation they classify as a "hybrid" - a complex version of Turbolinks - where client state is managed server side.
The term SSR keeps being used in a variety of ways.
In many contexts it implies firing up client side JavaScript on the server to generate markup and state to be sent to the client which then takes it and runs with it.
I personally avoid using "SSR" to mean "Classic SSR".
«The Rails Hotwire» reference here should probably be «Hotwire Turbo Streams». Since Hotwire is written in TypeScript and can run with several types of backend (like Django, with turbo-django).
«Turbo Streams deliver page changes over WebSocket, SSE or in response to form submissions using just HTML and a set of CRUD-like actions.»
turbo.hotwired.dev/
Based on the this "NEW MAGIC" was renamed to Hotwire in December 2020. I have no doubt that the implementation continued to evolve.
The point really is the order of emergence:
Thanks for this, it shed light on many things.
I used to struggle to know which tools, methods and techniques to use. Now I have a bit on an idea what to think of when building sites.
Awesome article these are some really advanced concepts.
Awsome article.
did u discover it? lol
Anyway Thank you for making this article.
I would add something that places traditional CMS's into context because many websites are still using traditional CMS's.