Everyone has JavaScript, right?
kryogenix.org
kryogenix.org
ALWAYS keep in mind that people are coming to your site for the text almost exclusively. If your stupid JavaScript interferes with the consumption of said text you have failed as a developer.
I think we need something that is to websites as markdown is to word processor files.
Or worse, unmangled text in JS source. Or text that's set to display:none until the JS gets to it.
If you're going to compile things clientside (looking at you, markdown), at least put the raw text in something the browser can display before the JS compiles it.
We sorta had that, but CSS and Javascript got bolted on.
Some of these issues are fixed with https or http/2. Some with CDN fallbacks or just sane coding. Some are not developers problems - such as clueless users installing malicious extensions or luddite users switching off js.
Why not ask 'Everyone has html, right?'.
http://jakearchibald.com/2013/progressive-enhancement-still-...
The web is no longer a collection of text content with links and forms. Many, is not most, web apps cannot be represented using html alone as progressive enhancement suggests. The core functionality just isn't there.
That's exactly the use-case of server-side JavaScript! Write a small library to build curl commands; use it in both the web page's JS and on the server, with a small shim on each. 1¼ times the work.
Just implement it as a regular form-based application, then add some JavaScript which Ajax-submits the form data and loads in the generated curl command on each keystroke.
(Or you could use server-side JS and share code on the client and server)
Should every chat app have a non-JS fallback option? Do we need to implement all color scheme, layout and templating tools in pure CSS?
Facetiousness aside, the web is most definitely not just text based anymore. Whether we like it or not, the web is now in part visual (and aural) and is becoming increasingly moreso. This is not a bad thing. It provides a platform for rapidly developing and deploying applications that cover the full gamut of uses we have thought up for the personal computer.
Using JS to simply display static content is overkill and not the best use of the technology and it is absolutely correct to say that this is better served by using Plain Old HTML. That is not the entirety of the web anymore and the more I see this argument that every web app must support a text only interface the more it sounds to me like an argument for every television show and movie to be produced as a radio drama with pictures.
Is it really that hard to add "We're sorry but your page did not load correctly" ?
I suppose I should have more verbosely indicated the facetiousness of the first few rhetorical questions but they do serve a point.
Also, I'd argue that the application-based web is still a minority compared to the content-based web, and you should check what side your site is really on.
Web applications are certainly useful in some contexts, and progressive enhancement may not be the best approach if your application requires a lot of extended interaction. But building a web app to display primarily text- and picture-based articles and documents is misguided, and it does web users a disservice.
So if I run arbitrary, potentially-malicious code from the Web, in the form of a browser extension, I'm "clueless"?
Yet if I don't run arbitrary, potentially-malicious code from the Web, in the form of JS, I'm a "luddite"?
Considering that many browser extensions are implemented in JS, the only difference is in control: users can pick and choose which browser extensions they want to use (I use a few; I've skimmed the source of a couple and written a couple myself), whereas enabling Javascript turns a machine into a third-party free-for-all.
Vanilla js running on webpages should be considered relatively safe. It's sandboxed and not able to do anything - malicious of not - outside it's restricted environment. It can't even get your location or lock a cursor without asking for permission first.
If you could somehow disable all logic from executing in your OS native apps, would you do this by default?
That argument is like the one that Linux is more secure because a malicious program will only have user rights.
Malicious scripts can do plenty of damage inside their restricted environment. There are whole books on how to securely write web apps due to the danger of "sandboxed" malicious JS.
Personally I don't want to be tracked and profiled yet nearly every major website is running multiple tracking and profiling scripts.
>If you could somehow disable all logic from executing in your OS native apps, would you do this by default?
I do disable native apps ability to communicate with the network unless they actually need it.
P.S. I also find that those who take a pure "webapp" approach introduce design flaws into their apps. In Toggl for example when browsing summaries you can't open multiple tasks in detail because instead of using a hyperlink they use JS to fetch and display the task details. Any content link should be able to be opened in a new window/tab.
Malicious things within the sandbox however, are a free for all.
I've certainly recompiled native applications to throw out 'features' I don't want, but my "default" is to just not install such programs to begin with. Especially these days, since I tend to use minimalist "do one job" programs, rather than giant "desktop environment" stuff like Gnome/KDE. That applies to my phone too, since it runs a stripped-down install of Debian.
The number of exploits requiring JS versus the number of exploits not requiring JS seriously disagrees with that opinion.
JS is a dynamic language that browsers put a lot of effort into JITting to be fast and limiting memory usage. And as such, the engines are complex. And as such, it's inherently hard to keep safe.
The v8 engine has literally over a million lines of code.
> If you could somehow disable all logic from executing in your OS native apps, would you do this by default?
Yes. And I actually do this on a regular basis. There are a lot of things I'll only run in a VM, or run in a VM the first time to see what it's attempting to communicate with / do (and occasionally block said communication for later). Not perfect, but better than nothing.
I don't want pages to reload unexpectedly.
I don't want a site to break standard UI behavior.
I don't want externally hosted scripts to track my activity.
None of this adds value to my experience as a user.
I do want to view the content - ideally in a single HTTP request.
Just load the damn content.
If you can live without it (the "progressive" part of progressive enhancement implies that the site is still usable without the JS), then I don't think you should be using JS at all. Semantic HTML and CSS are pretty amazing at adapting content fluidly and dynamically to a wide range of users and devices. Search engines expect documents to be laid out in a certain way. Web scrapers can add a whole pile of usefulness even to sites that don't create explicit public data APIs. You're going to have a serious hell of a time making it any better, and can easily make it a lot worse.
And on the other hand, content sites aren't the be-all, end-all of the Web anymore. The Web is increasingly a deployment platform for applications, and there are a whole host of applications that just can't be done in the browser without JS. Luddites who complain about "but I got JS disabled" aren't the target market for an image-editor-in-the-browser. Failing to load JS at that point is just plain failure to load the application and no amount of Progresso Soup is going to help you.
So yeah, I much prefer all or nothing.
And that's fine. I don't think any one should complain when you open a webapp and it requires you to have JS enabled. The problem is that when I go to a website with JS disabled, I often don't get any messages, but blank or simply broken pages.
The former obviously needs a proper scripting language. The latter should definitely be built with progressive enhancement in mind because it's a good thing.
Why this urge, on either side, to immediately apply their issues to an area which doesn't warrant it? Apps can't be progressively-enhanced without making things stupid. Documents shouldn't rely on javascript to be readable (in most cases).
I wonder, have there been any experiments in major browsers to execute non-javascript code?
Later versions of IE were able to run .NET code, which was what SilverLight was all about.
So imagine that, it was basically just MS leading the charge, which is probably why we only have JavaScript now.
I think they actually did for a while, but you had to use a flag to enable it?
(I actually wish they'd have gone ahead with adding the VM... I guess the utopia will be for another day)
Chrome currently supports NaCl, which allows running native-compiled non-JS code in the browser, but doesn't provide direct DOM access. A number of technologies have been used to provide non-JS code in browsers through plug-in APIs. And IE has directly supported, at different times, a number of non-JS languages in the browser as well.
So, yes, and not just "experiments".
You currently have to do that on HN too, so you can see how annoying it is.
It's a disingenuous argument introducing an artificial dichotomy.
If I can make a working website in HTML, but it works better with some additional JS, why exactly shouldn't I improve user's experience?
And on the other hand, content sites aren't the be-all, end-all of the Web anymore. The Web is increasingly a deployment platform for applications
Somehow I don't see a lot of these "applications". All I see is overly complex website that don't work without JS because developers don't know any better or don't care.
And I do see applications in the browser, because I write them. It is really hard to imagine how 3D graphics and virtual reality have anything to do with traditional HTML and browsing habits.
The lives of designers and developers are a million times easier if you just ignore accessibility requirements, too. But you know what? If you can't make a good design that caters to a variety of consumers, then you're not a good designer. Design is about melding form and utility, not just making something pretty. The less utility you have, the more you are an 'artist', and the less you are a 'designer'. Besides, if you don't care about anything but the most common, optimum user, you may as well return to the "This page best viewed at 800x600 on Netscape Navigator" '90s.
By taking an extreme position for the user, but not for the designer/developer, you're not making a fair comparison.
In the same way that designers don't force all visitors to calibrate their monitor colours before opening the site in Photoshop, to be as "authentic" to the "experience" as possible; likewise those of us browsing in Emacs or whatever don't expect your Unity-powered Minecraft clone to work for us.
What we do expect is that text-heavy, 'unavoidable' sites (eg. for governments, banks, etc.) aren't built inside Unity-powered Minecraft clones.
It also highlights the importance of progressive enhancement.
Answer: Microsoft. Their legal team started the browser-as-OS delusion with their 1990s freakout about Netscape; this was an anti-consumer, anti-competitive lock-in strategy which now masquerades as a fundamental principle of Good Clean Living for people who give speeches about their startup's Beautiful, Human Responsive Javascript Libraries or their genius-revealing reimplementations of Emacs that can only edit one language (namely Javascript.)
Hence today instead of having a computer, we have DMCA-hardened thin clients, and with each click we download what amounts to a freshly-coded never-debugged malware-infected EULA-wrapped software update; and when you enter a subway tunnel the whole universe stops working.
Yet on the linked essay he likens turning off Javascript to removing the steering wheel from your car, which I find to be both idiotic and revealing: Your steering wheel doesn't stop working when your car goes into a tunnel. But you can see why a Googler thinks like this: Google makes a car with no steering wheel, which really might stop working properly when it loses signal in a tunnel. The real benefit of Thin Client is to the employment prospects of Javascript programmers, to the Google whose Android and browser and Javascript VM you will need to do anything useful or performant on Googlephones, and to the war criminals in technology, finance, and intelligence who carry out the destruction of human culture via airdrop of free surveillance-gathering Javascript phones, where Responsive Javascript libraries conspire with distant servers to jack up the valuations of this or that group of ten HN-darling companies, and hire three or four guys to make sure the top comment always defends Apple's weekly anti-competitive "this is what's best for consumers" move, or reminds users that There Is No Way To Prove This Isn't Another Tech Bubble.
The whole concept of browser-as-OS has turned out to serve the permanent security state and other old-money beneficiaries of the Bronze Age kulturkampf. Thanks to the thin-client revolution and DMCA, secure software that actually WORKS is mostly illegal.
You have expressed many problems with js clearly out.
Is there a solution ?
I do not see a better alternative, I didn't start programming in js out of spite. I tried to learn the old neckbeard C infrastructure formally and it seemed to be a mess. Even though I understand how most of it works, if you are trying to create products of value to people you really cannot use it.
Hopefully my kids will experience a better experience with computers but for now js will do.
<3
Are you scared for advocating something that will be down-voted mercilessly ?
All in all this is expertly executed.
If the JavaScript fails to load and you were using it to significantly alter the content on your page, for example loading a news article asynchronously, the entire page fails to load.
I don't mean to pick on this app in particular (I actually think it's really cool and I plan on using it and learning from it), but take a look at what happens to http://hswolff.github.io/hn-ng2/ when you switch off JavaScript--it's completely unusable. Now try switching off JavaScript on Hacker News--all the links and comments are still there.
Worse. Half the time the content is sent synchronously in the initial HTML, but keep hidden until a JS script has its way with it. Looking at you Markdown.js.
For me, I run with noscript. Most of the places I frequent (here for example!) work great without any JS, other places less so, but I can selectively enable what needs to run, and many times when I find those sites that simply don't work without javascript, I just click back, and ignore them. I don't trust sites that can't at least load some basic content to convince me they aren't just a malware vector.
Yes JS may not work 0.1% of the time. So let's fix it once all the higher priority issues are fixed.
There are lots of good reasons to not do any of those things but until you come up with a universally acceptable alternative and convince the majority of people to adopt it, you're shit out of luck.
There are 2 interpretations of the situation. Either that 1.1% is a totally pressing issue and almost the entire industry is an idiot for not getting it; or the industry is actually pretty smart and also market forces do their work and it turns out it's not as a pressing issue relative to other things. I like to subscribe to the second idea.
Just a though.