There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress).<p>Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on).<p>Whereas, take the junior to mid developer streams. Every time there's an opportunity to learn something new and break the grind from doing [X] for the past [Y] months, there tends to be unwarranted justifcation on why "we should use this new thing" despite there already being a well-known and battle-tested solution sitting right there.<p>For example: We need to build a basic company website. Someone from reception needs to be able to update the contact form and trading hours around five times per year. Someone from marketing needs to update product brochures once a month.<p>Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end.<p>Junior - mid engineers: EW WordPress! Doesn't that use PHP? Hahaha. Hahaha. Why on earth would we want to be known for using _PHP_!?!? We'd be _far_ better to just create a front-end on react and then write a microservice that will allow our staff members to update content. If marketing says SEO is necessary, we can _simply_ add a server-side rendering layer for the react front-end and deploy it onto a second microservice. And to make sure it all works, we can subscribe to some monitoring services, write a full test suite and CI pipeline. Everyone can install monitoring on their phones so if it ever goes offline, someone can immediately sign in remotely and debug which micro service is broken.
This is something that I see espoused by "web traditionalists" for lack of a better term. Sure, there are a lot of web developers who are not optimising for performance but I think the difference is that it has simply shifted to the frontend where it's more noticeable.<p>The kinds of people who care about performance in the backend are exactly like the kinds of people who care about performance in the frontend. There's a variety of techniques that make sense in both areas to create a snappy, seamless experience. You need experienced engineers to create performance no matter what your domain is.<p>We've gone down the route of creating SPAs to largely replace experiences that would require desktop applications (it was only 5 years ago that I had to download an executable to do my tax return, now I do it with an SPA). Rather than create an SPA for a blog or a simple marketing site, we've largely replaced traditional "heavy"[0] infrastructure (PHP, Apache, MySQL just to display static content) with static JavaScript-generated sites. Many of these can simply be hosted on a CDN because they have no database and often no need for complex routing.<p>Pretending that SPAs were part of some dark ages is just silly. Horses for courses. If your application requires what I've dubbed "heavy" architecture (above) then by all means! Such infrastructure allows a high traffic service to be highly available, but is not required to serve a single .html file.<p>[0] When I say "heavy" I'm mainly talking about the attack surface and maintenance required. WordPress is great for serving a blog but has been the target of many hackers due to the amount of security vulnerabilities it has had over time.
Wouldn't do it any other way.<p>I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc.<p>I was regressing to the environment I understood in the early 2000s-2010s. I did all of this because I knew there would be a steep learning curve going into modern ecommerce and it seemed reasonable to put everything into <i>hibernation</i> while I attempted to go <i>all-in</i>.<p>I pretty much missed the entire React, Angular, Vue ramp up in the industry.<p>I've since shut down that ecommerce project and find myself peeking back to the js-verse every now and then.<p>I doubt I'll ever voluntarily use one of those frameworks for web dev.<p>I do, however, like this thing called, Svelte.
Good. I could do without the JS, to be honest (I'm a little tired of pages that refuse to show me <i>anything</i> unless I whitelist some stupid third-party jQuery script in uMatrix), but, baby steps.<p>When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, <i>thank God</i>.
Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and the latest Chrome.<p>A site like YouTube doesn't need to work with old stuff like Netscape or IE but if your site primarily focuses on text there's next to no reason there should be Javascript on your site. Sites like danluu's[0] and Michael Norman Williams'[1] may not look the best but they <i>just work</i>.<p>My website: <a href="https://www.instantfloppy.net/" rel="nofollow">https://www.instantfloppy.net/</a> (though admittedly I don't spend as much time on it as I should)<p>[0]: <a href="https://danluu.com/" rel="nofollow">https://danluu.com/</a><p>[1]: <a href="http://michaelnormanwilliams.com/" rel="nofollow">http://michaelnormanwilliams.com/</a>
> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost!<p>Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- in the browser. And hey, if you use a lot of the same logic and data models in the browser as you do on the back-end server, it's only natural to want to try to centralize the code. DRY. The problem is basically what @s_y_n_t_a_x said: developers got carried away with it and starting using SPAs for everything, including sites with low interactivity like blogs, which turned out to be less performant.<p>> But the web is about presenting content first and foremost!<p>Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?<p>In the end, the article makes the right point: Use the right technology for what you're trying to build.
> I find it fascinating that we are back to generating separate HTML/CSS and JS files and then putting them on a static file server — the CDN. It has been a decade long effort and as we come back to where we started, I feel like we are at a whole another level (a spiral?).<p>"The wheel of reincarnation" from client to server and back: <a href="http://www.cap-lore.com/Hardware/Wheel.html" rel="nofollow">http://www.cap-lore.com/Hardware/Wheel.html</a>
No, the SPA hype has warn off and people realize that although these new technologies exist, they are not always needed.<p>If you are building a web app, use React or similar.<p>If you are building a web site, use plain HTML+CSS w/ supplemental JS.<p>Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML.<p>Maybe don't embed all that stuff in your app and you wouldn't struggle with forms and routing, something that browsers can do very well with no programming.
It’s a nice title but webapps have evolved from documents to application bundles.<p>It’s super cool that we built wildly complicated apps out of what was in spirit an FTP client with a PDF reader but it makes since that we have to hack the document retrieval system less now that the client can run code.<p>Maybe one day we’ll stop hacking on the document store’s limited RPC-ish protocol too.
"All of this has happened before. All of this will happen again."<p>I was recently considering that we went through this cultural shift with computing: we started out by having a system to run code onvdistributed to terminals, then to actual desktop computers, then back to remote with the cloud, and now pushing out to "edge" computing. I'm sure it's more nuanced than that, but we seem to do these cycles, refining our processes.
It seems the trend points to slower and slower websites with more JS bloat. I also notice a increase in JS-errors causing entire sites to malfunction, recently this happened to large apps like Teams and Float
> But the web is about presenting content first and foremost<p>This is where the article started going wrong. I don't care about the web -- it's a tool for me to do my job. I use the web because it's a much better alternative to shipping a Swing app. I don't care what the web is "about" and neither do my clients.<p>Also I do think it's funny the JAM stack he's referencing is just the jQuery stack of 5-10 years ago.
> <i>And so was born PHP, it feels like a natural extension to HTML itself.</i><p>My ageing memory may be failing me, but wasn't Perl the first widespread language to be used for CGI ?
The leap from static HTML to PHP misses a big chunk of dynamic web site growth that started to produce a lot of the bad patterns that lived on.<p>As simple and nice as static HTML is, it's inefficient. The reason we care about this now is mostly:<p>A) A lot of people just hate Javascript. And a lot of that hate is understandable.
B) People still worry about the crawlability of their SPAs<p>JS has a lot of problems but it's also fixing some of these by growing really fast (paradoxically, also one of its problems).<p>Bots will get more comprehensively better at rendering client-side only apps.
I’m by no stretch of the imagination a modern web developer. I know plain JS well, HTML and enough CSS/Bootstrap to throw together an internal website.<p>Even then most of my experience is with server side rendering.<p>However, for any large project, I would much rather be forced into using a modern framework than not. Any web app that is large enough is going to have some type of bespoke framework that was created by the “architect” who has been there forever.<p>It’s just like dealing with a bespoke ORM, logging, or authentication/authorization framework.
We are not going back full circle. We are facing new challenges and realizing how complex web development is.<p>1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases.<p>2- There is no simple HTML either. Are you going to memorize how you coded <i>that</i> widget. Maybe use a framework (like bootstrap) to standardize things.<p>3- JS is not simple too; and the struggle is real. I remember coffeescript and then how EcmaScript 2015 tried to implement some of that nice stuff. Then you have TypeScript, because if your JavaScript is complex enough you might need stronger types.<p>4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM.<p>5- Then you have JS interacting with your server; because who wants to reload the page multiple times. And there are different ways to do that too: Ajax, REST, WebSocket, GraphQl.<p>6- Now that things are getting too complicated, maybe add a build tool in the process (like Grunt) and a package manager too (npm). They might not be that good, so time to build new ones (gulp/webpack/yarn).<p>tl;dr: Developing for the Web is complicated. Any attempt to make it simple is going to add to the already complex ecosystem which brought us here in the first place.
Off: Also there is the HTML Hell Page, which is older than many of the current web-developers but still contains the most relevant informations about web-design.
This is a strange way to define static. To me, a static site is one which doesn't make dynamic requests. Sure, it might load in static images (even static JavaSceipt!), but it would run fine if all resources were burned to a CD and loaded without networking.<p>A static site may be archived. It may be used with any browser at all. It will probably be useful even <i>without</i> a browser.
I think we just all have to agree that plugging a complex, dynamic component into a web site should be done with care and attention to the details.<p>If you need to offer some dynamic element to your website, such as a form that does validation, then just add a form that does validation with the most minimal of code, bloat and everything else.<p>Why is this hard?
We've been building Levels.fyi as a static website for the past 3 years! To create a new page, we simply hit new file on our text editor and start to fill the page. We have a simple build system + templating with Gulp and Nunjucks, but its really all we need.<p>Scaling a static site is incredibly nice & cheap too :P
I have a repo of static HTML pages with my personal documentation (I develop firmware). When started it some years ago, I almost chose WordPress, since I know it from running a small store.<p>I didn't wanted the hassle of a DB, theming, etc. Why can't I edit webpages with Dreamweaver like 25 years ago?<p>Then I've found Hugo (<a href="https://gohugo.io/" rel="nofollow">https://gohugo.io/</a>), set a template in like 5 minutes and now I edit my docs directly in VSCode and see them change in realtime. Also, the docs can be easily versioned (git in my case).<p>For a dumb like me (in the web-developing sense), static pages are a blessing. I am glad we are "evolving back".
Hello!<p>Article author here - I wrote this after realising that buzz words have entered our industry again in the form of the JAM stack terminology. Hence I took an approach of actually what is going on under the hood.
I am trying to bootstrap a SaaS business by myself and chose to split between SPA+rest for the product itself and static html + CSS + vanilla js for the landing page and documentation. I chose this because I've got limited resources and am not a designer, but with react I can get a nice polished interface quite quickly using things like material UI. I really tried hard to keep the tech as simple as possible while providing the quality I want and this was the best option.
I'm sure that <a href="https://svelte.dev/" rel="nofollow">https://svelte.dev/</a> is not the end goal of web development, but it is the next step.<p>What I want to see is more support for serving svelte and integration between front end components and backends. (I.e., the backend has a list of root components generated by the front end and a route can return one of those components in a statically typed way)
Everyone looks at tooling like Gatsby+netlify to support their dreams of a JAM stack, but vanilla html/JS/CSS can do a lot written by hand too. I recently replaced a whole WordPress blog by saving it from the browser and cleaning it to the point where non-devs have an easier time updating it on GitHub than struggling with the mass of config pages and plugin shortcodes they needed before.
As stated in the article, these ‘static’ files are being programmatically generated by backend services on remote servers rather than client side, but I don’t see how this could be construed as a paradigm shift back towards static site design. How can you call dynamic, per-request content generation as static design?
> Playing football is very simple, but playing simple football is the hardest thing there is<p>This quote is from Johan Cruyff - A football legendary. I feel it also true with programming.<p>Nothing wrong with the technical stacks, in my opinion: Do the right work, at the right time, with the right tool.
I don't even mean for this to be a plug but it's really easy to start up a VueJS site. I have done it multiple times.<p>```
npm i -g vue-cli;
vue-cli create my-app;
cd my-app;
npm run build;
aws s3 cp --recursive dist/ s3://my-site/;
```
> But the web is about presenting content first and foremost<p>Surely this just translates to user first ..? Devs moving from "it's about me" to "it's about you", perhaps with a bit of a shove from google, et al.
Static site generators work so well for a lot of sites. Why anyone ever thought they needed ASP.NET MVC or PHP or whatever else and a database all for the sake of a simple blog/article site is beyond me.
question... i keep hearing people say that when you use something like react, you need to have some sort of ssr in order to do any sort of seo. is that really necessary since google and other search engine can parse out js nowadays?
Honestly, static CMS like wordpress is overkill. A simple client side templating language and a JSON representation of your dynamic content is both sufficient and highly productive