481–490 of 573 posts
This is how I used to build web apps 20 years ago! :)
Render all HTML on the server side using a lightweight templating engine, make page loads fast and make all interactions reload the current page avoiding all client side JavaScript for validation and logic. (except for hotkeys for quick nav)
Earlier quoted context omitted.
No, the argument has never been "replace all JS with static HTML/CSS". The argument is "JavaScript frontends are becoming unnecessarily bloated, slow, and complicated, and we can do better". Solutions like the one Basecamp is proposing with Hotwire include pushing as much rendering logic as possible to the server, where you're using a language like Ruby for logic. Nobody thinks you can just remove all logic from a we…
“Bloated.” This is actually the opposite. Go into a language like python and install numpy (30mb) and then come back to complain to me about a 2mb js bundle. This argument is so bogus if you look at alternative language dependency sizes.
> JavaScript frontends are becoming unnecessarily bloated
Earlier quoted context omitted.
cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time.
> cgi-bin didn’t give you the ability to update a chat page across several different windows in near real-time. Servers could maintain an open connection and stream new data to the browser.
Earlier quoted context omitted.
If by surprisingly little, you mean 4 pages and 500mb of requirements for a "hello world" project with the "modern" web, then yes. The DOM has always been a mess, much like javascript. And the fact that no one has tried to do something about it contributes to the mountains of duckt tape. It was bad enough when angular showed up, but when all the other mumbo jumbo showed up like react, vue, webpack and whatnot is when…
> If by surprisingly little, you mean 4 pages and 500mb of requirements for a "hello world" project with the "modern" web, then yes. React is well under 20k. FWIW when optimizing my SPA, my largest "oops" in regards to size were an unoptimized header image, and improperly specified web fonts. There are some bloated Javascript libraries out there, yes. But if you dig into them you will often find that they are bloated…
So it's effectively similar to just a normal HTML page, but without things like headers and sidebars etc. being retransmitted?
I guess I am old but I don't understand why this requires a multi-million dollar marketing effort and all of the other stuff they invented on top of it.
Okay this is a bit meta, but the whole cluster of "everything old is new again", "the pendulum of fashion has swung", "nothing new under the sun" takes is ignoring what tends to drive this sort of change: relative costs. The allure of xmlhttprequest was that over connections much slower than today, and with much less powerful desktop computers, a user didn't have to wait for the whole page to redownload and re-render…
I think what drives this crazy train of overengineered solutions of SPAs and K8s for hosting single static page is deep separation of engineeres from the actual business problems and people they are trying to help. When all you have are tickets in Jira or Trello you don't know why you should do or if they actually benefit someone then it's natural to invent non-existant tech problems which are suddenly interesting to solve. That is natural for curious engineers and builders. Then mix in 1% of big apps and companies which actually do have these tech problems and have to solve them and everybody just wants to be like them and start cargo culting.
Generally people argue that static HTML is more energy efficient than server side rendering. I wonder If that is true in the case of static HTML "that loads an SPA", versus a server-side rendering with a proper cache in place. The SPA loading will still consume good energy on each client computer. Would love to see some numbers. Lots of hype, lots of projects and approaches, and lots of opinons about what is more con…
My intuition is that network transfer uses almost no energy, on a marginal basis, because the network links are always on anyway. When you pay for bandwidth, you're paying the amortized costs of building and maintaining the infrastructure. Rendering a SPA on a client device consumes CPU time, which definitely uses energy proportional to the number of client devices. Assume the server uses less clock cycles to render…
Earlier quoted context omitted.
Surely a JSON payload is almost always going to be considerably smaller than the contents of that payload laid out in an entire HTML document?
It’s not the entire HTML document, it’s piecemeal. As for sizing equivalent data in HTML vs js, I remember reading an investigation that XML and JSON are generally closer than you would expect and that for some data structures, XML is terser.
If you're not invalidating the cached code multiple times per day (which, in fairness, a lot of the stuff from Google, Facebook, etc probably are), an SPA should use less data over time than a comparable server rendered app. The initial outlay is bigger, but once it's cached you only need the raw data as you navigate around.
Time will tell --I'm not so bullish on Hotwire-- but one has to admire figures the likes of DHH that can almost single handedly change the status quo of the industry.