
Websites have evolved back to static HTML/CSS/JS files - diablo1
https://paramaggarwal.substack.com/p/how-websites-evolved-back-to-static-html-css-js-files-57ce549f81db
======
jonny383
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).

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).

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.

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.

Seasoned engineer: Let's use any well-tested CMS such as WordPress and install
a caching front-end.

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.

~~~
pjc50
We're back to "The boring solution has a long list of inconveniences and
uglinesses that everyone knows about. If we chose the new solution, nobody
would know where the bugs are and we can have exciting new ones."

Really the problem is that the standard solution hasn't improved. Backends are
_still_ a hassle in the 2020s. People keep reinventing CGI.

Every now and again I think "why doesn't someone just produce a simple
standardised solution that would be cheap to host and easy to write", and have
to lie down until the madness goes away.

~~~
scoutt
> "The boring solution has a long list of inconveniences and uglinesses that
> everyone knows about. If we chose the new solution, nobody would know where
> the bugs are and we can have exciting new ones."

Is this C vs Rust again? (it's a joke, but go ahead, downvote).

~~~
pjc50
Oh, it's practically general purpose life advice. You could even apply it to
some people's second marriages.

------
chrysoprace
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.

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.

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.

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.

[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.

~~~
torgoguys
SPAs being the darks _ages_ is over-the-top, but being an SPA when other web
architectures could better serve the user is a dark _pattern_. That tax app
doesn't need to be an SPA. JavaScript powered interactions make the experience
nicer for the user, but that doesn't mean it needs or is improved by being a
single page.

~~~
wyqydsyq
If it's a web-based user interface as this tax app sounds to be, it is
arguably improved purely by being an SPA. Requiring full page reloads just to
submit or change some tiny bit of data in a page is objectively bad UX.

~~~
julianlam
Besides doing my taxes on paper, I can't think of anything more tedious than
filling out tax forms via a vanilla HTML form.

At least my SPA tax software makes the form filling a little more exciting,
and doesn't s#!t the bed when I hit enter by accident

~~~
colecut
Simple form validation would prevent that, not exactly SPA worthy.

------
popup21
Wouldn't do it any other way.

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.

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
_hibernation_ while I attempted to go _all-in_.

I pretty much missed the entire React, Angular, Vue ramp up in the industry.

I've since shut down that ecommerce project and find myself peeking back to
the js-verse every now and then.

I doubt I'll ever voluntarily use one of those frameworks for web dev.

I do, however, like this thing called, Svelte.

~~~
jakelazaroff
_> I doubt I'll ever voluntarily use one of those frameworks for web dev._

 _> I do, however, like this thing called, Svelte._

Svelte is just another one of “those frameworks”, except with a vastly smaller
community:
[https://trends.google.com/trends/explore?geo=US&q=svelte%20i...](https://trends.google.com/trends/explore?geo=US&q=svelte%20is,react%20js,angular%20js,vue%20js)

~~~
akiselev
Svelte components compile to vanilla javascript plus a small runtime (a dozen
or so functions that track state for context and the developer tools). It's
much lighter weight than React or Vue's runtime and a side effect is that
integrating Svelte components into other frameworks is a breeze (especially if
you compile to web components). The author refers to it more as a separate
language.

I've had a great experience with it recently developing a smart tv app - which
are dog slow even with a quad core ARM CPU due to the resolution so I decided
to learn Svelte for the project. The big downside is another templating
language to learn and as you said, the community is tiny, but the surface area
is small enough that it hasn't been a problem regarding tooling or debugging.
Pulling in other frameworks into a svelte app is also relatively easy so it
can be part of a slow incremental rewrite, although as always it devolves into
a webpack/rollup config mess.

~~~
wyqydsyq
> Svelte components compile to vanilla javascript plus a small runtime

Same could be said of React though. React components are literally just plain
JavaScript functions which return VDOM nodes that get diffed and applied to
the DOM by the runtime library.

The only objective advantage I see to Svelte is it's tiny footprint, which if
you really need you can already get by using Preact (3kb vs Svelte's 3.5kb)
without having to learn yet-another-completely-arbitrary-templating-language
to no benefit.

~~~
pests
Svelte is actually quite a bit different. Quoting a random section from their
docs

"[Svelte is a] compiler that knows at build time how things could change in
your app, rather than waiting to do the work at run time"

My point being there is a large amount of compile time code transformation at
build time. The run time is not so much a framework as a library like libc. In
Svelte when you update state there is no virtual dom, dom diffing, fibers, or
anything. It would have been compiled into a direct dom update of anything
depending on it. It's no longer a Svelte app just vanillajs. There are some
details or course but it's a different paradigm than to react or other modern
UI frameworks.

------
AdmiralAsshat
Good. I could do without the JS, to be honest (I'm a little tired of pages
that refuse to show me _anything_ unless I whitelist some stupid third-party
jQuery script in uMatrix), but, baby steps.

When sites finally ditched their trendy Flash rewrites and went back to HTML,
I thought, _thank God_.

~~~
geggam
Be interesting to see if we could start charging website owners fees for them
using our processing power to render their site.

Something needs to be done to encourage some efficiencies given the fact it
takes more resources to surf the internet and read about running a k8s cluster
than it does to actually run the cluster

~~~
p2t2p
You're free not to use any website...

~~~
geggam
Arguably if you are publishing content on the net you are giving it away.

There are mechanisms to charge for it.

~~~
hombre_fatal
> There are mechanisms to charge for it.

Only above a certain price point. Our financial system nor our consumer
culture support micropayments yet. This effectively limits the web properties
that can charge users to a small fraction, so unfortunately "just charge
money" isn't the widely-available solution I wish it was yet.

Hell, it's more viable to charge users for your mobile client than the backing
service. It's kind of the closest we have to micropayments in a way.

~~~
geggam
Then you dont have a sustainable business model.

Why should I subsidize your failed model ?

~~~
buzzerbetrayed
Yet you somehow think charging content providers for using your computer when
they give you free content isn’t a failed business model?

~~~
geggam
If someone gave you a set of unassembled Ikea stuff and you didn't know if you
could use it until you assembled it.

Who should pay for the assembly of the stuff ?

Would you put it together for free just to decide ?

Who pays for the used resources ?

------
RandomGuyDTB
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.

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 _just work_.

My website: [https://www.instantfloppy.net/](https://www.instantfloppy.net/)
(though admittedly I don't spend as much time on it as I should)

[0]: [https://danluu.com/](https://danluu.com/)

[1]: [http://michaelnormanwilliams.com/](http://michaelnormanwilliams.com/)

~~~
justanotherc
I have no idea what your site is about. Its just random links with no
explanation about what they are or for.

~~~
RandomGuyDTB
> (though admittedly I don't spend as much time on it as I should)

It's pretty much just a howto and link repository for myself and my friends
right now. Still mostly a work in progress. Consider it as an example for look
rather than for function.

------
x3haloed
> 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!

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.

> But the web is about presenting content first and foremost!

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?

In the end, the article makes the right point: Use the right technology for
what you're trying to build.

~~~
WDCDev
> Use the right technology for what you're trying to build.

Yep .. so if you want a rich responsive user experience, DON'T use any web
technologies. GMail (AND Gsuite) is a perfect example of how a relatively
simple concept like email can be turned into a slow, unresponsive piece of
garbage.

~~~
karatestomp
I'm about 99% sure the store on the PS3 was webtech. That beast of a machine
could barely run its own store. They lost a _lot_ of money from me as a result
of the store being super-slow, input laggy, and crashy (OOM I assume), and I
can't be the only one.

PS4 feels like they've taken webtech all over the OS interface. Its store's
snappier than the 3 but the rest of the interface performs way worse. Usable,
but far less pleasant.

[EDIT] store _should_ be snappier than the 3, mind, since it's way more
powerful hardware—it's still kinda slow, considering.

~~~
paranoidrobot
All sorts of devices with some kind of UI are using a browser in some kind of
kiosk/headless mode.

STBs, Smart TVs, IFE systems are or were web based.

~~~
zitterbewegung
To be honest as time goes on the Smart piece of your device starts to get
slower and slower.

One of the main drivers for getting a amazon fire stick is that it is much
more responsive than the Smart TV itself.

~~~
tonyedgecombe
I thought that but the Youtube app on both my smart tv and Apple TV are broken
in exactly the same way and unusable without a regular reboot.

------
gwern
> 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?).

"The wheel of reincarnation" from client to server and back: [http://www.cap-
lore.com/Hardware/Wheel.html](http://www.cap-lore.com/Hardware/Wheel.html)

------
s_y_n_t_a_x
No, the SPA hype has warn off and people realize that although these new
technologies exist, they are not always needed.

If you are building a web app, use React or similar.

If you are building a web site, use plain HTML+CSS w/ supplemental JS.

Sometimes your project can be split in half. Do the landing page, signup,
login, privacy policy, etc. in plain HTML.

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.

~~~
woutr_be
> If you are building a web app, use React or similar.

I disagree with this, there's no reason to use React/Vue/Angular for a web app
by default. And I would urge people to try and avoid it for as long as
possible and see how far you get. From personal experience I can tell you that
most of the time, you don't need a frontend framework to build a web app.

~~~
s_y_n_t_a_x
From my professional experience throughout the last decade, you're wrong.

I urge people to practice and use the best tool for the job, don't avoid
something because some hipster thinks it's too popular.

Feel free to go back to jQuery spaghetti code, it's nice until you build
something too big.

React isn't a framework btw, it's just the view. You can stack anything or
nothing with it.

------
Spivak
It’s a nice title but webapps have evolved from documents to application
bundles.

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.

Maybe one day we’ll stop hacking on the document store’s limited RPC-ish
protocol too.

------
sircastor
"All of this has happened before. All of this will happen again."

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.

------
cjohansson
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

~~~
camccar
New reddit is painfully slow to login. So much javascript for a simple dialog
to load it's absurd.

~~~
qznc
As long as old and compact reddit are still there, I'm fine with it. Twitter
on other hand has no lightweight version, unfortunately.

~~~
benbristow
Twitter's redesign is one of the most performant SPA's I've seen in a while.
It's really smooth and nicely designed too. A lot better than their previous
webapp.

~~~
zuzun
When I open a Tweet I look at spinner animations for 10 seconds. Scrolling is
also the opposite of smooth.

~~~
benbristow
Scrolling is silky smooth for me and spinners go away quickly.

What hardware are you running?

~~~
zuzun
For their infinite scrolling, they clean the DOM above and below the viewport
and only keep a certain amount of tweets rendered. So once you start scrolling
a little faster, the JavaScript can't keep pace and starts sputtering.

------
ng12
> But the web is about presenting content first and foremost

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.

Also I do think it's funny the JAM stack he's referencing is just the jQuery
stack of 5-10 years ago.

------
Jaruzel
> _And so was born PHP, it feels like a natural extension to HTML itself._

My ageing memory may be failing me, but wasn't Perl the first widespread
language to be used for CGI ?

~~~
stan_rogers
Well, C was there first in that sense, but yes, you're broadly correct. But
that misses the point. PHP was developed and released as a templating language
- something anybody with a bit of basic HTML knowledge (and, frankly, _all_
HTML knowledge was basic HTML knowledge back then) could use to build an
interactive site by using HTML-like tags to employ code written by somebody
else as widgets in an HTML page. Perl meant writing the whole thing, including
emitting HTML from the code.

------
nkozyra
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.

As simple and nice as static HTML is, it's inefficient. The reason we care
about this now is mostly:

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

JS has a lot of problems but it's also fixing some of these by growing really
fast (paradoxically, also one of its problems).

Bots will get more comprehensively better at rendering client-side only apps.

------
scarface74
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.

Even then most of my experience is with server side rendering.

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.

It’s just like dealing with a bespoke ORM, logging, or
authentication/authorization framework.

~~~
snypox
Plus shifting processing from backend servers to end user browsers can be a
huge plus of you have a decent amount of visitors. Also, just simply pushing
my code S3 is so much easier for me than building a Docker image and putting
it into a container orchestrator.

------
csomar
We are not going back full circle. We are facing new challenges and realizing
how complex web development is.

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.

2- There is no simple HTML either. Are you going to memorize how you coded
_that_ widget. Maybe use a framework (like bootstrap) to standardize things.

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.

4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM.

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.

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).

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.

~~~
Guest0918231
Well, I completely disagree. Compared to developing sites 15-20 years ago, I
think it's a walk in the park now. I feel like I can achieve far more with
less code, the tools are more powerful, the code is easier to read, and there
is much more consistency across browsers.

Did you want to make a box with rounded corners?

We can do that now... <div style="border-radius: 5px; border: 2px solid
black;"></div>

It's intuitive and easy to understand. Try that 20 years ago. You're designing
that in Photoshop, slicing up images for each corner, placing them into
countless HTML table cells, messing around with all the table and cell
heights, widths, paddings, margins, and borders, and struggling to get IE to
render it correctly. That could have easily been an hour of work, and it would
have resulted in a mess of images and inflexible code. Now, it's one line of
code and 10 seconds of work. Did you want to fade the color of the border to
red when the user hovers over the box? We can do that with two lines of CSS
now. Good luck trying to achieve that in the past.

What do you mean thousands of lines for a responsive/mobile CSS layout, and no
simple HTML?

[https://www.w3schools.com/html/tryit.asp?filename=tryhtml_re...](https://www.w3schools.com/html/tryit.asp?filename=tryhtml_responsive_media_query3)

There, it's a site with a header, footer, navigation, three columns, and it's
responsive. 36 lines of CSS and 36 lines of HTML. Add 5-10 lines of CSS to
reset spacing at the beginning, and that could literally be an entire
responsive website.

~~~
overcast
The basics are easier yes, but the projects have become more complex. So yes,
we can easily round corners instead of silly image slices, but like anything,
making things easier just bumps up the expectations.

------
lzsiga
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.

------
zeveb
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.

A static site may be archived. It may be used with any browser at all. It will
probably be useful even _without_ a browser.

------
movedx
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.

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.

Why is this hard?

------
zuhayeer
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.

Scaling a static site is incredibly nice & cheap too :P

~~~
movedx
> Scaling a static site is incredibly nice & cheap too :P

And secure. The only back end systems to attack are load balancers and web
servers -- if you're self hosting those then just make the file systems read-
only and now you're talking seriously tough security barriers between you and
an attacker.

------
scoutt
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.

I didn't wanted the hassle of a DB, theming, etc. Why can't I edit webpages
with Dreamweaver like 25 years ago?

Then I've found Hugo ([https://gohugo.io/](https://gohugo.io/)), 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).

For a dumb like me (in the web-developing sense), static pages are a blessing.
I am glad we are "evolving back".

------
trynewideas
The best part is that this is from an email newsletter and has broken HTML at
the end.

------
paramaggarwal
Hello!

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.

------
alephu5
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.

------
eximius
I'm sure that [https://svelte.dev/](https://svelte.dev/) is not the end goal
of web development, but it is the next step.

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)

------
jkoudys
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.

------
melq
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?

~~~
SPBS
You serve the same HTML/JavaScript/CSS bundle to anyone who visits your site,
and the JavaScript renders the request specific details on the client (by
making more calls to the backend)

------
vinhnglx
> Playing football is very simple, but playing simple football is the hardest
> thing there is

This quote is from Johan Cruyff - A football legendary. I feel it also true
with programming.

Nothing wrong with the technical stacks, in my opinion: Do the right work, at
the right time, with the right tool.

------
aantix
..and Rails, billed as the anti-enterprise framework in its early days, just
added sharding support.

------
fiofio
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.

``` npm i -g vue-cli; vue-cli create my-app; cd my-app; npm run build; aws s3
cp --recursive dist/ s3://my-site/; ```

------
somishere
> But the web is about presenting content first and foremost

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.

------
lloydatkinson
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.

------
egypturnash
My personal site is still a bunch of files served up by a cache in front of
Wordpress. It'll be cool again in a couple years, I guess.

~~~
paulmd
The really cool kids are just using something like Jekyll that does all the
templating at publish time and you just have static files you dump onto a
server.

------
pjmlp
Ironically for those of us on SSR frameworks, it was fun to just watch the
pendulum go back and forth, while we just kept delivering.

------
thrownaway954
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?

------
smitty1e
All of which makes the idea of some sort of JSON-driven API very, very
attractive.

------
wideasleep1
Would have been apt to use 'devolved'. 'Are We Not Men?'

------
5cott0
If SPAs are the dark ages then what do you call the IE6/7 jQuery days?

~~~
jonnycoder
The Wild Wild West!!? I remember doing jquery/ajax calling an API and while it
was easy to churn out spaghetti or long js file code, it was still easier to
read and pick up a few years later.

~~~
5cott0
> it was still easier to read and pick up a few years later.

Compared to what?

------
sigzero
Does that mean a new version of Microsoft Frontpage is imminent?

------
apatheticonion
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

