4 ms·

> There are loads of cases where building something in JavaScript is easier than HTML. Yeah, I'm aware of these cases. I'm not demanding your web3.0 real time

> There are loads of cases where building something in JavaScript is easier than HTML. Yeah, I'm aware of these cases. I'm not demanding your web3.0 real time interactive multiplayer pokemon clone work without JS. But it would be nice if the text and images on your root index page would load without JS, so that I could decide if I want to run your arbitrary code on my computer without feeling like I'm rolling the dice. > Because a non JavaScript version of lots of applications means a dynamic server generating HTML. You haven't heard of page pre-generation have you? You could use JS to generate all the basic html you need, save that, and serve it somewhere from some basic HTTP server. Then the site would still do something without JS. > I would argue that building secure, user oriented data-backed applications out of JS clients with backend microservices in the JAMStack style is actually easier than doing it in classic serverside scripting LAMP stack or Ruby on Rails style. I would argue the exact opposite, but this absolutely comes down to familiarity. I've written more python and html than I have JS. But what's easier still is writing a basic blog with the exclusive intent to deliver information, rather than increase growth, retention, conversion, or whatever metrics sales/growth is asking for today.

jameshart 5y ago
A basic blog can obviously be built using a simple DB-backed server side framework. The original blogs were basically designed almost entirely around the capabilities that were easy to accomplish with that architecture - you can practically read off the underlying relational table structure of Dave Winer’s blog from the RSS spec. As you render each page serverside you just SELECT in the blog content, the index links, the tag cloud, etc. But it has to be said (speaking as someone who has implemented this a few times) comments were always the tricky bit. You’re right that SSR/pregeneration approaches are a reasonable modern approach to building a simple blog, but still comments are an annoying obstacle to a simple pregenerated page model. And I’ve got to say: it for sure gets a lot more complex when what you’re building isn’t a blog but a blogging platform. I’m absolutely not arguing that such a system shouldn’t serve up relatively simple prerendered HTML for article pages by the way - I mean, basic SEO kind of pushes you to do that - but that the rest of the stuff on that blog - the tag clouds and the comments and so on - are actually easier to add through clientside JavaScript integration of simple backend services, than through adding complexity to your serverside HTML generation model.

jameshart 5y ago

A basic blog can obviously be built using a simple DB-backed server side framework. The original blogs were basically designed almost entirely around the capabilities that were easy to accomplish with that architecture - you can practically read off the underlying relational table structure of Dave Winer’s blog from the RSS spec. As you render each page serverside you just SELECT in the blog content, the index links, the tag cloud, etc. But it has to be said (speaking as someone who has implemented this a few times) comments were always the tricky bit. You’re right that SSR/pregeneration approaches are a reasonable modern approach to building a simple blog, but still comments are an annoying obstacle to a simple pregenerated page model. And I’ve got to say: it for sure gets a lot more complex when what you’re building isn’t a blog but a blogging platform. I’m absolutely not arguing that such a system shouldn’t serve up relatively simple prerendered HTML for article pages by the way - I mean, basic SEO kind of pushes you to do that - but that the rest of the stuff on that blog - the tag clouds and the comments and so on - are actually easier to add through clientside JavaScript integration of simple backend services, than through adding complexity to your serverside HTML generation model.