Earlier quoted context omitted.
Security matters, and blocking JS blocks the majority of vulnerabilities on browsers. We should help users who want to protect themselves.
No. If I develop an interactive website, I'll be damned if I try to also keep the No-JS folks satisfied. Either you trust me, or you don't.
A JavaScript-Free Front End
201–210 of 215 posts
Re: A JavaScript-Free Front End
#202Earlier quoted context omitted.
No. If I develop an interactive website, I'll be damned if I try to also keep the No-JS folks satisfied. Either you trust me, or you don't.
Do you vendor your javascript libraries and host them from your own domain, or do you just hotlink them from random CDN's all around the internet like everyone else? If you're hotlinking them, I don't trust you.
Re: A JavaScript-Free Front End
#203Is it popular to hate on JS these days? Kudos to the author for creating the stuff but would you build the next Amazon.com avoiding JS? More often than not, I see Backend developers taking pride on not using JS rather than vice versa. Also, FB and GOOG aren't naive to spend enormous capital and manpower on React and Angular projects. Probably will get downvoted but just because someone writes pure C does not make him…
Re: A JavaScript-Free Front End
#204There is something like that the Elixir web community is trying to do with Liveview, Texas, Morphling and Whistle. Several competing libraries doing the same thing I believe, I've only seen Texas and Liveview in action. The whole point, iirc, is to manipulate the DOM on server side and push those changes via a websocket. So the DOM manipulation is on server side and the code is server side language Elixir. There was…
Re: A JavaScript-Free Front End
#205Earlier quoted context omitted.
Do you vendor your javascript libraries and host them from your own domain, or do you just hotlink them from random CDN's all around the internet like everyone else? If you're hotlinking them, I don't trust you.
One could use Subresource Integrity ( https://hacks.mozilla.org/2015/09/subresource-integrity-in-f... ) to mitigate the most obvious threats from CDNs. Granted, that does have some maintenance work, but if you're already managing dependency versions (and you really should) then it's minimal extra work.
I rarely feel that website owners out out to get me, my distrust comes from scripts that load scripts that load scripts. Lets not piss about, I know most people who have written websites that are loading jquery from a remote CDN haven't bothered to inspect it to see what it's loading. By contrast, a website that has vendored all it's script dependencies has looked at the entire dependency tree at least /once/. That shows a baseline level of competence that I'm willing to extend trust on top of.
Re: A JavaScript-Free Front End
#206Earlier quoted context omitted.
A reasonable argument iff you use no external libraries, or personally audit every one of them completely (including all updates). Otherwise maybe I trust you, oh random person on the internet, but should I also trust the 49 authors of the 37 libraries you're including from 4 different CDNs? (Bonus points if you run ads and let under-vetted 3rd parties inject whatever they want into the page)
But why should he put time into supporting you?
The answers actually pretty simple. People who are interested enough in technology to read hacker news are both disproportionately likely to discover a new product trying to build an audience, and disproportionately likely to influence their friends either for or against that product. They're trusted by their non-technological peers.
So why support script-blocking hacker-news users? Because if your website doesn't work for them, they're gonna tell all their friends that your product doesn't work properly. When I got my first job, I was told that on average satisfied customers tell 2 friends they were satisfied, and dissatisfied customers tell 12 friends they were dissatisfied. I don't know how accurate those stats are, but I do know people complain more than they praise.
I certainly go out of my way to warn friends and family away from products that I feel are committing technical faux pas. How else will they know they're using websites made by people of limited technical capability, with all the risks that implies, if I don't tell them?
Re: A JavaScript-Free Front End
#207Earlier quoted context omitted.
This can’t be true, right? A ton of major applications (Google’s for starters like GMail) have some layer of post processing or obfuscation (or maybe it’s just compiled) to their generated DOM that results in a ton of nested divs with gobbledygook classes.
It's not the DIV-soup that is an accessibility problem (though that's what often takes the blame), it's the lack of adding accessibility attributes (`aria-*, tabindex, title`, etc.). Lots of builtins, especially form elements, give you many accessibility traits "for free", but there are a wide variety of ways to tag a bowl of DIV soup for accessibility. Then there's "semantic HTML(5)" (` , `, etc.), which still exist…
Re: A JavaScript-Free Front End
#208This write-up mostly highlights the loading speed and bandwidth benefits but not requiring javascript is far better than just that. In the age of spectre and with browsers exposing more and more bare metal functionality the idea of running arbitrary code on every random site I go to is absurd. There's dozens of us that simply don't run JS. Sites like these (and, say, the way chicago public media does fallback for no…
> There's dozens of us that simply don't run JS Was this intentional? It gave me a bit of a chuckle.
Re: A JavaScript-Free Front End
#209I've been using intercooler.js ( http://intercoolerjs.org/ ) on a project recently and absolutely love it... basically, it's allowed me to develop a web app with a modern feel without writing any JavaScript. Highly recommend it!
Why the downvotes?
Re: A JavaScript-Free Front End
#210> I built the first version of Slimvoice on Angular 1 with a Node.js backend and MongoDB in 2014 (those were all the rage back then). In 2015 I decided to completely revamp the UI and redesigned and rebuilt it in React. Maybe you should make decisions based on requirements instead of hype. Oh wait: > Don't follow the hype But using less javascript is the hype today... > Plain Old HTML and CSS This section only shows…
Is it? This article on npm weekly (https://medium.com/npm-inc/npm-weekly-133-billions-of-packag...) says 4 billion packages were downloaded in a single week - representing multiple packages per week per human on earth. (Granted, this was Feb 2018, which is 2.8 millennia ago in JavaScript years.)
This site (on which you can't use the back button after choosing a graph) seems to show downloads still growing for popular packages. https://www.npmtrends.com/