41–50 of 101 posts
While the point may be true, it's like don't drive a car because people do die in car accidents. The post is misleading as most of the cards present rare edge cases where JS doesn't work. Show percentages as well. Yes JS may not work 0.1% of the time. So let's fix it once all the higher priority issues are fixed.
Earlier quoted context omitted.
At this point my mobile experience is go to website, read a couple of sentences, watch javascript muck with the layout as you describe, then a full screen popup wanting me to register or download the app, followed by a part of the top of the screen with a app store link for the app, then I get to read the article - maybe. I think we need something that is to websites as markdown is to word processor files.
I'd like a browser that just removes all the CSS and JS and gives me simply the text, like Safaris reader mode, but without the need to ever leave it.
[deleted]
If you use PE, then you just-so-happen to get IE5 and NN support, but you also get support for Chrome, IE10, FF, Safari, mobiles, etc.
If you don't follow PE, you're playing a high-stakes game of whack-a-mole: even if you only care about a few browsers, the combinatorial explosion of version/OS/screen-size/connection-speed/etc. configurations to keep track of can get ridiculous. If you miss out one combination, it can be game over: lost customers due to a white screen of death, or something equally unusable.
You could keep pouring more effort into whacking moles, or you could reduce the stakes of the game. If your "game over" scenario consists of a product screen with images, description, reviews, a search box and an order form, but no hover-over zoom feature, it doesn't matter anywhere near as much. You no longer need to worry as much about missing a few configurations, and can focus on fixing bugs and adding features. The fact that it might also work on IE5 and NN is just a bonus; it's certainly not the point.
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.
Earlier quoted context omitted.
Initial server-side rendering is still an option. User will be able to read the page, at least. And if URLs use a sane scheme, navigation would work too
Not an option. Concrete examples: anything webgl, image editing, games, even a simple curl app from yesterdays post (curlbuilder.com). Implementing curl app server-side would require double work which is against principles of progressive enhancement (or programming in general).
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.
Earlier quoted context omitted.
and if there's nothing on the page to read? 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 rapid…
> Should every chat app have a non-JS fallback option? 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.
Right, but these problems are not specific to javascript requests. Any request can fail, be blocked, interfered with, or partially received. Users can switch off CSS, too. Html page may not load completely. So what? 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…
> such as clueless users installing malicious extensions or luddite users switching off js. 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…
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?
The thin-client revolution is finally here, and what an awful pile of shit it is. Whatever happened to software that just works? 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 startu…
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