4 ms·

Since when is writing JavaScript easier than HTML? what amount of extra complexity and special tooling is required to make it easier to "ship" HTML? I by no me

Since when is writing JavaScript easier than HTML? what amount of extra complexity and special tooling is required to make it easier to "ship" HTML? I by no means am I ann all JavaScript is bad zealot, but I do browse with it disabled by default so I don't have to trust that every single third-party developer is good enough to prevent some malicious douche nozzle from injecting some rogue script that either turns my web browser into a botnet, starts mining crypto for somebody, or exploits the newest silicone defect and is now uploading my in-memory keys to some cloud provider. and while I would agree it's unreasonable to expect complete functionality from your site with the scripting disabled, I don't think it's unreasonable to expect your page to at least partially load. I get it JavaScript developers for the most part don't give a shit about security* but some of us do and it would be nice if it wasn't a constant battle between the two of us. *to you the random JavaScript developer who actually does care you notice I didn't say all but you have to admit your colleagues are often guilty.

Wowfunhappy 5y ago
Pure HTML+CSS websites are, of course, way easier to code than ones with heavy Javascript (Assuming we're talking about hand-coded websites, and absent other factors like the developer's personal familiarity.) But there's also things you can't do without Javascript. For example, if you want a fade-in animation to play when the user scrolls to a certain spot on the page, you'll probably want to calculate the user's scroll position with Javascript. If you don't address the no-JS case specifically, the element will never fade-in for users without Javascript!
- grayhatter 5y ago
  > had-us-in-the-first-half.gif lol, you got me in the first half there; I was already mentally constructing my reply before I eventually got the sarcasm :D Well played!
- deleted 5y ago
  [deleted]
- 411111111111111 5y ago
  You should be able to do that with pure html/css as well by abusing the newish lazy load feature and probably some SVG! Yay for modern web
jameshart 5y ago
There are loads of cases where building something in JavaScript is easier than HTML. Because a non JavaScript version of lots of applications means a dynamic server generating HTML. 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.
- grayhatter 5y ago
  > 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.

Wowfunhappy 5y ago

Pure HTML+CSS websites are, of course, way easier to code than ones with heavy Javascript (Assuming we're talking about hand-coded websites, and absent other factors like the developer's personal familiarity.) But there's also things you can't do without Javascript. For example, if you want a fade-in animation to play when the user scrolls to a certain spot on the page, you'll probably want to calculate the user's scroll position with Javascript. If you don't address the no-JS case specifically, the element will never fade-in for users without Javascript!

grayhatter 5y ago
> had-us-in-the-first-half.gif lol, you got me in the first half there; I was already mentally constructing my reply before I eventually got the sarcasm :D Well played!
deleted 5y ago
[deleted]
411111111111111 5y ago
You should be able to do that with pure html/css as well by abusing the newish lazy load feature and probably some SVG! Yay for modern web

jameshart 5y ago

There are loads of cases where building something in JavaScript is easier than HTML. Because a non JavaScript version of lots of applications means a dynamic server generating HTML. 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.

grayhatter 5y ago
> 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.