[bad_user]

You're talking about "progressive enhancement". It's a romantic idea, but it never happened, probably because it's too hard and the cost is not justified given most users run with their browser's default settings.

The precursor of the web made by Tim Berners-Lee dates back to 1980, but it was not based on HTML or HTTP. These happened later in 1990 and early 1991. But then CSS happened in 1994. And Javascript happened in 1995 at Netscape, but then Javascript was completely useless until Microsoft came up with the iframe tag in 1996 and then with XMLHttpRequest in 1999, which was later adopted by Mozilla, Safari and Opera. And people still couldn't grasp its potential until Google delivered Gmail in 2004 and Google Maps in 2005.

Not sure what the "the web was meant to be", we should ask Tim Berners-Lee sometimes, but in my opinion the web has been and is whatever its developers and users wanted it to be, with contributions from multiple parties such as Netscape, Microsoft, Mozilla, KDE/KHTML, Apple, Google and many other contributors, being a constantly evolving platform.

[ams6110]

It was Microsoft with Outlook Web Access that really was the first big example of what was possible. I worked with several folks around that time and we were doing "rich" web apps in IE5 with XML data delivered from the server via xmlhttp and building the presentation in the browser with XSLT. It was really slick, especially at the time, to be able to filter and sort, do summary and detail views, etc. all without a page refresh.

[jacquesm]

CSS happened in 1996, the first couple of years of the web we had no CSS, all styling was done with inline attributes up to that point.

The frustrating bit is that CSS was supposed to separate content/structure and markup, but now we have pages without content but with markup where the content is loaded after the fact. This really overshot the mark.

[TeMPOraL]

Also note tat the separation of content and structure is mostly nonexistent as it's currently practiced. People like to talk about it as a Golden Rule, a holy virtue, and then proceed to write even worse code than they did with tables. Generally, if you find yourself writing a tangled mess of divs in order to support CSS tricks, you're not really separating content from the structure. HTML5 semantic tags helped a little, but I still rarely see them used live.

(I'm not really convinced that separation of form and content is a feasible goal anyway - some elements of form are also content at the same time - but it's still a good goal to have.)

> now we have pages without content but with markup where the content is loaded after the fact

This is absolutely ridiculous and it, combined with the idea of routing everything through the cloud in IoT / home automation applications, makes me wonder what happened to some good old-fashioned engineering sanity. It's like people are trying to create wasteful and insecure systems on purpose. ("And what would that purpose be," - the cynic in me asks - "maybe monetizing people's data?").

[spion]

Have you considered that there may be an actual reason why people write a tangled mess of divs. Could it be because the entire model is crappy and people don't know what to do to make it show things the way they (or their client) want(s)?

[talmand]

In my experience, as a front-end developer, the usual reason I need a mess of divs and spans is to support a design that's not a good idea for a web page to begin with.

[spion]

What is a web page, and why would a particular design not be a good idea for it?

If a web page is not a good idea, then what other technology should be used to achieve that design, as well as remain equally easy to distribute?

This mindset is precisely why native mobile applications continue to exist on the market, and why articles like this one fail to convince me. Nobody (except perhaps Facebook with React) tries to really fix the web to meet the demands its been given. Instead everyone insists that the demands should change to meet the original vision and limitations of the web.

Regarding the HTML/CSS interplay, flexbox gives me some new hope that reconciliation is possible (getting both semantic markup and powerful / precise styling).

[talmand]

It's easy to find designs that are bad ideas for web pages. The most obvious culprit is a design that's excellent for a magazine layout. Such designs typically don't take into account the document flow nor the idea that different people open their browsers to different resolutions and browser window sizes. Heck, some won't even take into account different browsers with different capabilities. I think I understand where you're going with the "what is a web page?" bit, but it doesn't necessarily apply. Especially since a web page can be whatever anyone wants within the limitations of a browser, but that doesn't mean a design works based on some person's idea of what they think a web page is. In most cases a design is limited by the browser, not necessarily by the code of the page.

I have no idea what you mean by your second sentence.

And then, are you referring to my mindset or some other mindset? Because I fail to see how you can know my mindset on the matter. If it's the other, I would agree. Except I would say that "fixing" something in terms of making it do something it wasn't intended in the first place may possibly create more problems than we are attempting to fix. I would suggest attempting new things to see if they work, which there are some doing just that. I would point out that flexbox is an example of this.

I'm excited with flexbox and have started pushing to make use of it more often, when warranted. It's hard to switch current code to it, but I think it's worth it. But, in the end, someone will eventually start complaining about its limitations and that it needs to be "fixed". Then we'll be back where we started, it's inevitable.

[TeMPOraL]

> This mindset is precisely why native mobile applications continue to exist on the market

And long live them because there is little about the mobile experience that's more infuriating than a web app that should have been made as native. The assumption of being always on-line is baked too deep into the web stack; I have yet to see a well-made web app that could not be made significantly better UX-wise by simply going native.

[pdkl95]

> it's too hard

It's only hard if you want it to be hard. Your tools should be handling most of it for you. If they don't, pick tools that aren't broken or badly designed. When I was writing websites in Rails 2.x, progressive enhancement was usually automatic (same views are rendered as a page or a dynamically-loaded partial).

Saying "It's hard because I want to write over-complicated pages with badly designed tools" isn't good engineering or good design.

> most users run with their browser's default settings

How, exactly, do you know this? If the answer is "analytics", you are missing an increasing amount of data.

> constantly evolving platform

Which is why you progressively enhance pages. Those of us that disable javascript for safety usually get blamed when this topic is brought up, but the main reason for progressive enhancement is that it's defense in depth. You don't know what the browser is, what options it has set, what bugs it may or may not have, or if extra page assets even made it successfully over the network.

Not bothering with progressive enhancement is shoddy programming for much the same reason you shouldn't skip the test for NULL after calling fopen(3).

edit: grammar

[Joeri]

I don't know a single person IRL who turns off javascript. It's the browsing equivalent of running only RMS-approved software, possible in theory, but not very practical, and definitely rare. The business needs of modern commercial websites are hard to build with progressive enhancement, and web apps basically require javascript to deliver a good user experience. Yes, you can build a personal website using progressive enhancement, and at one point I did, but I had to give up my progressive enhancement ways when i became a professional web dev because it was just not practical to do otherwise.

[TeMPOraL]

Web apps can be excused, but most web sites? Not really. What exactly happened that made it not practical to write simple sites? Did browsers suddenly stop rendering HTML unless you generate it in JavaScript?

It's not business needs, it's cargo-cult web development. Going with the latest trends without a moment to stop whether it makes sense or is actually what the users want.

[Too]

What exactly is the issue with having the HTML generated with javascript? You can still run "view source", overridden CSS or Greasemonkey on it...

[TeMPOraL]

Why do you need to generate HTML with JS in the first place? There rarely is a need to do so on a website. There's definitely no need for the e.g. loading content of a blog post dynamically just to achieve a fade-in effect[0]. And yet, most of the modern web practices is silly stuff like that.

[0] - https://news.ycombinator.com/item?id=10646025

[M2Ys4U]

It's not only people who actively disable JS, though. See the How many people are missing out on JavaScript enhancement? blog post[0] by the UK's Government Digital Service (aka GOV.UK).

They calculated that 1.1% of users don't have the JS enhancements activated, and only 0.3% of those were browsers where JS execution was disabled.

[0] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...

[datashovel]

I would guess a majority of that traffic is going to be crawlers. It's probably more like a small fraction of 1% who are actually missing out.

EDIT: Looks like they covered this in comments. Even that doesn't convince me for some reason.

[pdkl95]

Crawlers load images from <noscript> tags? Some might. As googlebot runs Javascript, would an image inside <noscript> be indexed into google image search?

While that's an interesting question, one of my points was about this common type of claim:

> guess

You admit you don't actually know. I don't either, which is why I program defensively and test for any feature I want to use.

A lot of people seem to be projecting what they want to see, reinforced by confirmation bias. Choosing Javascript based analytics is a great way to conclude that almost nobody uses Javascript.

[datashovel]

Good points.

https://addons.mozilla.org/en-US/firefox/addon/noscript/

https://chrome.google.com/webstore/detail/ghostery/mlomiejdf...

These are some very popular plugins, so my thinking is maybe the answer lies somewhere in between, where security-conscious users are white listing sites they want to run scripts on. Not that they're running completely in js disabled mode. Even though it's a subtle difference I think it's relevant to the strategy one goes in with regarding noscript tag.

So this would make sense to me. If that's right, that most noscript users are just running these plugins, then those folks know that they're going to miss out with some sites, or they'll selectively enable javascript on a case-by-case basis.

This would probably require more extensive review of logs, to see if the person who originally downloaded the noscript image eventually came back to the site with javascript enabled. The likelihood is this would only happen if the site was not functional when they visited with javascript disabled.

[JupiterMoon]

I don't know a single person that does not run an adblock anymore.

[userbinator]

I happen to know 3 (two of which I convinced into doing so --- and they're not even what I'd consider "advanced users"), and I am one myself.

The majority of informational sites are actually quite usable without JS. I'd say "the browsing equivalent of running only RMS-approved software" would be never allowing JS, but I'm more pragmatic and only enable it if necessary, for the sites I trust and must use.

[initself]

The web is whatever we want it to be, but sad that lack of agreement on standards and openness of platforms severely limits what it can be now without a massive sea change. Because collective agreements tend towards entropy, those with the power in the agreements hold on tight to prevent decline. When we become more conservative and restrictive in order to keep collectives in place (open web >> Facebook), it limits our freedom to innovate and development becomes "a fight to maintain" that benefits the few rather than "a forward thinking step-by-step process" that benefits more and more people.