Why? You can literally just put HTML on a server an start an HTTP server and you're done. How does JavaScript make that easier?

> Why should I spend time on that 1 lonely user who browses with JavaScript disables when I could focus on maximising value for the other 100,000?

Your webpage will be smaller and faster if you just deliver the HTML. I don't know what your website looks like, but it's not uncommon to see 4 MB of JavaScript transferred just to draw 400 bytes of text on my screen.

Moving HTML from your server to my screen is a solved problem, and using JavaScript to do that is just as silly as using Java, Flash, or Silverlight.

Why wouldn't the said someone take a day or two to update themselves on javascript tooling in order to get less confused? There are so many great resources available.

I do like this idea. However, as one of the minority of people who have disabled js by default, I'd hope this could be done in a way that doesn't break websites.

That's the entire problem with JS: i can't browse a page without a complex rendering engine (arguably full of security vulnerabilities) or even scrape it. Something like webmention/microformats (indieweb) federation becomes almost impossible with you due to your setup.

Also worth noting, rendering the Markdown on the client is super inefficient. First, because client-side JS will always be far slower than native code server-side: i first need to download the entire JS then run it in a super slow sandbox. Second, because there's economies of scale to be had: it may take a few milliseconds to build the markup, but every client has to do it. For n client, that's O(n) complexity vs O(1) for server-side rendering. So many CPU cycles wasted :)

You already can do it. Canvas, WebGL, SVG, and a bunch of 2D and 3D libraries.

I've been developing single page applications, mostly, for six years; and I generally don't enable JavaScript on a website unless it is otherwise broken and I actually care to use it. I'm developing a website right now that has some persistent elements (video call, interactive charts) that don't play well with server side rendering. For the elements that are fine without it I prefer to render them on the server when there are enough of them, but ultimately there are limits.

The point is to white list scripting on websites . It allows faster browsing, lessens CPU load and memory consumption and save battery life on mobile and laptop. Most websites do not need javascript to be turned on to be browsed.

I've been developing websites professionally since 1996. HTML/CSS/JS and SQL.

I am still amazed there is the crowd out there who is "anti-JavaScript". They run NoScript to only allow it in certain places, etc.

It's 2023, a small amount of JavaScript on a page isn't going to hurt anyone and will (hopefully) improve the UX.

For the record, the last site I deployed as a personal project had 0 JavaScript. It was all statically generated HTML on the server in C#/Sqlite that was pushed to Github Pages. So I get it, it's not necessary.

For my little personal site. I'm also the senior lead on an enterprise Angular project.

JavaScript is fine, it's not going anywhere.

And yes, there are way too many React (specifically) websites that don't even need a framework at all, but it's become the go-to. That annoys me too. But some JavaScript in 2023 is fine.

Unless I'm misunderstanding, this example seems to be exactly what I'm talking about.

Even in its current state, there are only 2 or 3 things on this page I can see using Canvas. Everything else is already using HTML and CSS. It's not even lazy-loading the images -- this is a static page that is dynamically generated. And yet despite ultimately being a static page, it works fine. Great even, it's responsive if I resize the browser. HTML is doing everything you would ever need here.

You can use Canvas for the (optional) background animations in the deep water, Canvas (or gifs) for a few minor animations like the waves on the top. You use a very small amount of JS to update the text tracker and swap the sub to a fixed position when you hit its scroll-point. The sub is already an image being animated via CSS, so you're doing that correctly.

To me, this page is the perfect example of something that has an incredibly simple tree-based UI that is nevertheless being dynamically rendered with webGL for some inexplicable reason. I'm actually a little annoyed that it doesn't currently work with JS disabled. I wouldn't expect the depth-tracker to work without Javascript, but I should still be able to at least scroll to the bottom and see all of the pictures and text. It would not be hard to make this page degrade gracefully.

What do you want this page to do that isn't possible with the current state of HTML/CSS? I might be missing something, but I don't see what the complication is.

> In my opinion what you see as 95% of all user interfaces is largely a because HTML and CSS are the rendering target not the other way around.

I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.

But maybe they should?

Like, I agree that if your web page loads a full MB of Javascript, eliminating JQuery should be the least of your concerns; it's a drop in the bucket, so optimize elsewhere. But web pages really shouldn't be loading 1 MB of Javascript in the first place.

It's so nice when I come across a website that's actually slim, I can really feel the difference...

I don't know how common it is, but I do. I have a secondary browser profile which does allow it, but frankly for just about any page I visit if it doesn't work without JavaScript I will skip it: the Internet is large and I rarely need to look at a page.

It's good to show what's possible but it isn't fun and will bore them to death fast because it's very limiting for beginners.

JS has its overhead in terms of data and, more severly, performance. Many people tend to put unecessary JS stuff like custom scrolling, needless animations and needless interactivity, etc. This stuff more often than not just ends up getting in the way of normal browser function and is of questionable benefit or none at all.

> I am building a website that relies heavily on JS. What should I be aware to steer away from the JS hate?

Don't add any JS interactivity that only makes a website "look cooler"* and that's not actually critical to your website's functioning. For example, stuff like google maps needs javascript. Stuff like blog most likely doesn't.

Remember to try out how your website works on a device with weak hardware and slow connection. This will not only make it far more accessible for people with older hardware, it will make better for recent hardware as well.

*) today's expression would probably be "rich user experince" or somesuch, but the meaning is the same - it's just vanity

This exactly. Every web browser has JavaScript, but there's no button to press to bring up a tab with a simple, easy to use JavaScript programming environment (e.g. a canvas, console, code editor, demo programs) with a link to beginner-friendly tutorials and documentation.

The button + tab would be easy to make, though tutorials/documentation would be a lot more work.

I am constantly surprised at the number of people that explicitly disable JavaScript to make their lives difficult in 2018.

My point is, JavaScript makes it easy to build nice websites at scale. Plenty of CMS platforms (like Wix.com) use JavaScript by default.

If 99.9999999% of people are fine with JavaScript, then why should a website cater to your need by providing a version specific to people who disable JavaScript?

Back in the day when I was working on the Sage Notebook, there weren't good javascript consoles. I can't recall if Firefox had one at the time (around 2007, I think), but it was certainly missing from Safari, IE, and Opera. But, it was an interactive notebook -- so I hijacked the "input cell" we were using to concoct what was essentially a console.

As an experiment I tend to disable JavaScript periodically. It is amazing how fast and responsive applications become. The amount of cruft that is downloaded is insane! Typically my experiments end after a month or so, because a lot of website don’t work _at all_ with JavaScript disabled.

I've used webkit.js (https://github.com/trevorlinton/webkit.js) to implement a client-side save-chart-to-image feature in an web app. Not really sure if I'd currently recommend it, but the strategy has promise if developed on more. Most people needing to do this right now for arbitrary HTML would probably be better served by having their webapp make a request to a server to run wkhtmltoimage and return the image.

The project isn't actively maintained and I never managed to compile it myself, so I wouldn't be able to effectively maintain or extend or fix issues in it. It doesn't have any hooks to call code when it's done rendering something, so I had to experiment and finally I noticed it would call a specific webgl method when it was done, so I would monkey-patch that webgl method to call my code afterward.

Then there's the issue that it's a 5mb download (gzipped) to the user's browser. It was only needed for a little-used feature, so I made the file not be requested until the feature is triggered, and then the download progress is shown on a modal. (And then the browser keeps the script cached after loading it once, so future uses of the feature are quicker.)

In the end, it works well for my use case here. Some parts of my use case that helped it work was the fact that immediate rendering wasn't necessary (it was fine to make the user wait for it to load), and the fact that it only had to work on HTML that the web app itself generated. webkit.js doesn't handle things like images or remote resources currently, so it wouldn't work well for arbitrary user-provided pages.

I don't really. In my comment I just wanted to mention more aspects to the problem. This is mainly a catalyst to show people there are more tools out there at our disposal that we sometimes think about.

And some of our tools need more research...