Tom identified the main weakness of modern web development correctly: It's based on javascript. He points out the sluggishness and accessibility problems that stem from that attitude, and hes absolutely right to do so. Static pages (as a paradigm, not as Gatsby in particular) are maybe not the cure for that, but they are definitely a step into the right direction.
I just rewrote my website with hugo and specifically without a major JS framework, but settled for a vanilla approach rooted in a progressive enhancement mindset. I didn't even run into the problems that are inherent to React, Vue and Angular.
Sure, you can serve HTML with SSR, but you still have to wait for the bundle in order to have a functional site, plus a truckload of ssr-related complexity. And that is utter rubbish. JS should never be a requirement, it needs to be put in its place as the cherry on top of the cake.
Progressive enhancement needs not only to be a major approach to webdevelopment again, it needs to be out default mode of operation.
This is also the core of Toms article. And I agree with him.
That said, nothing stops you from adding features like nice transitions. But please be sure not to break standard web features while doing so.
Transitions need to add to hyperlinks, not replace them.
I feel like you didn't quite read the article closely enough ;) Of course progressive enhancement needs to be the default — that's why there's so much focus on SSR in all major meta-frameworks.
Sure, you can serve HTML with SSR, but you still have to wait for the bundle in order to have a functional site
This isn't true! Take sapper.svelte.dev, which is a site built with Sapper and baked out as static pages. It works just fine without JavaScript, you just don't get client-side routing. It's a small site, but the same thing applies to larger ones like Gatsby's homepage — no JS? No problem.
It certainly is true for standard implementations of React-, Vue- and Angular- based sites. There may be a focus on SSR, but it still isn't close enough to deserve to be the default. It needs to come without extra complexity. Only then we're ready to take the step to fully embrace those solution.
And this is my point. You need to take one step after the other. It was a mistake to build everything with javascript first and then try to look if it still works without afterwards. The damage to the web has been done.
I didn't take a look at Sapper/Svelte. Though, in comparison, those are still a nieche product.
JS certainly caused a lot of damage on many websites. But now - finally - we're getting to the point of having frameworks which can, by default, offer client-side routing with SSR and hydration without shipping large bundles of JS. Up to this point the frontend devs should have been more conservative and they should have thought twice whether they should really go all-in into an SPA. But now's the time when it's really starting to be a viable option. Next, Nuxt, Marko and Sapper are finally technologies highly worth pursuing, even for content-based websites.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Tom identified the main weakness of modern web development correctly: It's based on javascript. He points out the sluggishness and accessibility problems that stem from that attitude, and hes absolutely right to do so. Static pages (as a paradigm, not as Gatsby in particular) are maybe not the cure for that, but they are definitely a step into the right direction.
I just rewrote my website with hugo and specifically without a major JS framework, but settled for a vanilla approach rooted in a progressive enhancement mindset. I didn't even run into the problems that are inherent to React, Vue and Angular.
Sure, you can serve HTML with SSR, but you still have to wait for the bundle in order to have a functional site, plus a truckload of ssr-related complexity. And that is utter rubbish. JS should never be a requirement, it needs to be put in its place as the cherry on top of the cake.
Progressive enhancement needs not only to be a major approach to webdevelopment again, it needs to be out default mode of operation.
This is also the core of Toms article. And I agree with him.
That said, nothing stops you from adding features like nice transitions. But please be sure not to break standard web features while doing so.
Transitions need to add to hyperlinks, not replace them.
I feel like you didn't quite read the article closely enough ;) Of course progressive enhancement needs to be the default — that's why there's so much focus on SSR in all major meta-frameworks.
This isn't true! Take sapper.svelte.dev, which is a site built with Sapper and baked out as static pages. It works just fine without JavaScript, you just don't get client-side routing. It's a small site, but the same thing applies to larger ones like Gatsby's homepage — no JS? No problem.
It certainly is true for standard implementations of React-, Vue- and Angular- based sites. There may be a focus on SSR, but it still isn't close enough to deserve to be the default. It needs to come without extra complexity. Only then we're ready to take the step to fully embrace those solution.
And this is my point. You need to take one step after the other. It was a mistake to build everything with javascript first and then try to look if it still works without afterwards. The damage to the web has been done.
I didn't take a look at Sapper/Svelte. Though, in comparison, those are still a nieche product.
JS certainly caused a lot of damage on many websites. But now - finally - we're getting to the point of having frameworks which can, by default, offer client-side routing with SSR and hydration without shipping large bundles of JS. Up to this point the frontend devs should have been more conservative and they should have thought twice whether they should really go all-in into an SPA. But now's the time when it's really starting to be a viable option. Next, Nuxt, Marko and Sapper are finally technologies highly worth pursuing, even for content-based websites.