I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?
The web is not about 'engaging web applications'; the web is about webs of interlinked documents. Every time you require JavaScript to display a simple document; every time you load images with JavaScript instead of <img>; every time you replace an <a href=> link with a JavaScript event handler; every time you fail to even link to a page; every time you use JavaScript-loaded fonts to display symbols: you break the web.
'Web application' is a misnomer: it should be 'browser application.' Despite my loathing for documents (e.g. blogs, articles &c.) which require code execution in order to be read, I don't mind browser apps where they make sense. Google Maps makes sense: it doesn't bother me that it doesn't work in eww, or links, or with NoScript.
Blogger doesn't make sense: there's absolutely no legitimate reason for it to show an empty page with JavaScript turned off: Blogger is breaking the web. imgurl's failure to show all images, and Cracked's failure to show any images, without JavaScript makes no sense: they are breaking the web.
People who break the web should be deeply ashamed.
There are some warts we need to sort out and get better at, but I still see it as progress.
If it doesn't work without JavaScript, it's breaking the web.
I have absolutely no problem with progressive enhancement. I have absolutely no problem with choosing to enable JavaScript when it makes sense. I have a problem with requiring a privacy-destroying technology in order to consume content.
If you want to serve an empty, broken page as a first impression, you can. I strongly recommend against it because it makes your site look half-finished, poorly designed, and generally unprofessional.
> available in the browser
That isn't always true. You don't know anything about the browser a priori.
> make a better experience
Of course. Javascript can add nice features, which is why you progressively enhance the page to add features when the underlying requirements are available. Do you skip the check for NULL when calling fopen(1)? Checking for errors is always important. On the web, this means you should gracefully handle problems like missing javascript (intentionally or otherwise) or other resources.
> Making UIs respond faster
Requiring two additional HTTP requests (one to load javascript, and another to load the actual page content) isn't making the page faster. After the first request your javascript will be available most of the time for partial loads in any case.
> interactive content
That is rarely a good idea, but it's your page so do what you want. Progressive enhancement doesn't affect this at all.
But that being said, ive been developing a heavy javascript SPA ( Single Page Application ) and have been writing javascript that is going to be very useful to (certain types of) users.
Im more than happy to download a large bundle of javascript (and css) if im getting an application (and preferably not on my phone)
And in defense of SPA's which dont even have web in them, good ones are a portal to a location on the web (a model type and id) loaded usually via json with html re-rendered on the client. And even better ones have history implemented. So they can feel very like the web...given js is enabled(!)
But of course I understand the "why reimplement what browsers already offer?" SPA's feel almost indistinguishable from a desktop app if done right...
What are your opinions on SPAs?
I think that some of them make sense, but many many many would be better implemented as RESTful apps instead. Once the REST layer is written and works without JavaScript, implementing an enhanced version which requires JavaScript and minimises redownloading of new data is relatively easy.
Imagine a chat app. The pure-HTML version could serve a chat message at /chats/{partner}/{message-id}, with a prev link to the previous chat; it could serve a chat sequence at /chats/{partner}/{message-id}?history={length}; it could redirect /chats/{partner} to the most recent message in a sequence. A form could easily enable POSTing a new message to the chat.
Once all that's done, it's dead-easy to write some JavaScript which ties it together in a single-page app. Instead of requesting each message as text/json, the JavaScript client could accept application/json (or another format, if you like). It could subscribe to a WebSocket or server events. It could do anything — but the basic HTML-based app would still work, and be usable from a command line, from a simple phone, from anywhere.
If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken.
This kind of evangelism makes no sense. The whole idea that "the Web is about documents, specifically" was shattered as soon as Javascript was added over two decades ago. It's no longer about that idea and hasn't been for a long time. Interlinked resources, yes, and documents became a subset of that idea in 1995.
The desire for document-type content to display without JS stems from a strange desire to see the technology used how it was invented in 1990. The Web was hodge-podge of technology then, and it's even more so now. If you intend to pick and choose what parts of the hodge-podge to use, you will find yourself frustrated forever. And you gain no advantage by arguing "but I want the _original_ hodge-podge to work with the type of content it was design for!".
JS _is_ the Web just as much as HTML because all (Edit: popular) browsers support it. As soon as that happened, compatibility with the Original Hodge-Podge was dead, permanently. For better or worse, that is the reality.
Before the prevalence of JS you could simply download the text. But now, much of the text interpreted. So if you wish to get all the text, you must also do the interpretation step. Which essentially means running a headless browser to pipe it to you. And it's simply not practical to tell your text sources to avoid using so much interpreted text. They're using Web standards.
Your second premise doesn't hold for all browsers: links cannot display Blogger pages; Firefox with NoScript cannot display Blogger pages; the Tor Browser with high security cannot display Blogger pages.
The Web is, fundamentally, about resources — documents — and their state, not about behaviour.
> JS _is_ the Web just as much as HTML because all browsers support it.
No. They. Don't. eww doesn't. w3m doesn't. lynx doesn't. links doesn't. elinks doesn't. Firefox with NoScript doesn't. The Tor Browser with high security doesn't. That is the reality.
The reality is also that allowing JavaScript exposes users to severe privacy and security threats. Disabling JavaScript is the only way to control those threats.
Every site which requires JavaScript to function is like a serpent tempting a user into giving up his privacy and security. That is the reality.
These configurations disable universal features, so the premise holds.
> The Web is, fundamentally, about resources — documents — and their state, not about behaviour.
Yes, in 1990. Also, you choose to conflate "resources" with "documents".
> w3m doesn't. lynx doesn't. links doesn't. elinks doesn't
These are browsers that choose parts of the standard hodge-podge and they suffer for it by not being able to display all pages.
_
I'm not arguing the situation is great or that you should like it. Hell, I don't even like it. Your criticisms of JS are valid. But your expectations of how the Web should work are _broken_ and they would have been broken 20 years ago. Whether it's 1996 or 2016, the only way your reality could come true is if there was an HTML-first programming style enforced universally. It's so impractical it's barely worth mentioning, so why evangelize?
> These are browsers that choose parts of the standard hodge-podge and they suffer for it by not being able to display all pages.
So, the Web is not broken because all browsers which use a feature are able to display pages which use a feature — anyone who disables that feature is responsible for breakage due to pages using it, and anyone using a browser which doesn't support that feature is responsible for choosing such a browser.
Your logic would justify every vendor-lock-in attempt from Apple & Microsoft; it would support the idea that all the Internet's IE.
> But your expectations of how the Web should work are _broken_
No they most definitely are not. My expectations of how the Web should work are based on mathematical truth. REST is symbolic manipulation: it's correct in the way that only math can be.
> Whether it's 1996 or 2016, the only way your reality could come true is if there was an HTML-first programming style enforced universally.
Not HTML-first, resource-first. Figure out what your resources are, figure out how they are related, figure out what behaviour makes sense, then wire it all together. Once you have all your resources (images, HTML, whatever) working well, then feel free to wire it up with JavaScript.
HTML's power is that it is declarative, not imperative. It shares that character with plain text: when you read my words you do not give me root access to your brain. No-one should be forced to execute unknown, newly-served code in order to read a document.
When you require JavaScript, you break the Web. Please don't.
Except in this case the "vendors" are the makers of every popular browser and the standards body governing Web technologies. Not exactly apples-to-apples.
> My expectations of how the Web should work are based on mathematical truth. REST is symbolic manipulation: it's correct in the way that only math can be.
Right, a programming style. Your 'mathematical truth' is arbitrary given current web standards. The lack of it does not break interlinking, which, by your own admission, is what the Web is about.
> Not HTML-first, resource-first. [...]
You didn't actually address the fact that you would need to have everyone follow this style. You expect the Web to work in a way that can never be enforced; that is a broken expectation. I agree, this is the way it should be done but it's completely obvious it won't ever happen. The incentive to follow that style is no where near enough to generate any sort of defacto standard. So why evangelize?
You feel wrong. I enable it when I have to, only.
> How can you build engaging web applications
Not my problem. I want quick loading sites with as few malware vectors as possible.
You should be building web applications which facilitate the transfer of information. You don't need javascript and all the other crap people are using these days for that. I mean, if you're all about pure eye candy and doing..I dunno, mandelbrots or something in the browser, then yeah, you're going to need javascript. But it's not going to work on mobile. Hardly anything like that works on mobile, which is fine by me; I do most of my browsing there.
To be honest, I think there's a market for a firefox addon which removes links to sites which don't work on mobile/require you to have javascript enabled to save me the effort of clicking back when i arrive at am empty page or when the screen is dimmed and all I can see is the corner of some dialog I have no interest in zooming out to look at.
I did it using javascript entirely client side, so it works offline, it's secure (as it doesn't send the images anywhere), and it is fast to load (letting you change settings and get the new cross-stitch in the blink of an eye).
With your idea of doing things, i would need to pay for a server (and would probably need to then charge my users who wouldn't pay, so it's now DOA), it would be significantly slower, it would be less secure/private, and wouldn't be able to do things like auto-change the size of the resulting image depending on the screen size of the browser (important for mobile! don't want to overload the browser with massive images).
That needs javascript, and for you and others to keep acting like anything that uses javascript is a toy that shouldn't exist is arrogant and wrong.
It's even the kind of thing that passes for a native application in Chrome OS.
And even as an app it's not that good. It's very single-purpose, there aren't really any "settings" that need to be saved, an app for this would be overkill.
As a website, it's quick to find on any device (desktop, laptop, phone, my damn TV!), it's extremely fast to install (if it takes more than a second to load on home internet i've done something wrong), has little to no footprint on the disk of the device, and does one thing and does it well.
I think it skews the conversation to talk about JS being "turned off", rather than unavailable, as it assumes that every user agent (browsers, screen readers, crawlers, CLI commands, etc.), even those cobbled together 5 minutes ago to do one quick job, is capable of running JS, has a DOM, is up to date, implements various APIs, that those APIs even make sense (what's the screen resolution of wget running in an SSH session?); and that the user has manually told it not to.
You can, but you an't force the user to interact with your 'web application' in the way you prefer. But you could never rely on the user's browser settings being optimal for the experience you wanted to provide anyway.
If you want absolute control over what the user sees and doesn't see, then build a native app. The price you pay for the ubiquity and convenience of web applications is putting control over the interface in the hands of browser vendors and end users.
What do you do for accessibility? Screen readers etc?