Live data from Hacker News

A JavaScript-Free Front End

dev.to

201–210 of 215 posts

Re: A JavaScript-Free Front End

#201

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.

Many won't and visitors will leave. New visitors will bounce more often. Users with trust for every site is low until earned.

Re: A JavaScript-Free Front End

#202

Earlier 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.

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.

Re: A JavaScript-Free Front End

#203

Is 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…

It is somewhat popular to hate on useless dung heaps of pointless Javascript, not because it's Javascript (writing complex code in a mediocre language with mediocre libraries is a separate concern), nor because backend developers have good reasons to do things in the backend, but because it's overcomplicated and so bloated that it causes performance problems, just like nested table layouts a few years ago.

Re: A JavaScript-Free Front End

#204

There 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…

I've played around with sending html strings via Phoenix channels and using morphdom to change only what needs to be changed. I'm quite happy with the results, even when sending an entire page for every significant change, and can't wait for LiveView to be released (estimated later this month, IIRC).

Re: A JavaScript-Free Front End

#205

Earlier 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.

Correct me if I'm wrong, but all the scripts the website owner hotloads have to also use subresource integrity for the scripts they are hotloading, or subresource integrity gains nothing beyond the first level of script loading?

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

#206
post #164

Earlier 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?

Interestingly I've had this debate with at least one person on hacker news who was complaining about how people were stealing from his website by running ad blockers, and how he'd tried to fight them but it had left his website looking broken for anyone who was running an ad blocker, so he'd had to roll it all back. Why would he do that?

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

#207

Earlier 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…

Ah interesting thanks for the info. I'm now wondering how accessible GMail for instance is. I'm see a lot of tabindex and aria-labelledby but the values seem to be garbage as well. But I temper that against my assumption that GMail, being such a universally used application, must have some mind towards accessibility.

Re: A JavaScript-Free Front End

#208
post #45

This 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.

I saw some actual statistics recently on a link from a blog with a lot of posts about accessibility (I forget which). It said that 1 in 98 users (1% of visitors) didn’t load JavaScript in a page, and 0.2% of visitors didn’t load the script because they had explicitly disabled JavaScript, as opposed to other reasons such as a poor network connection.

Re: A JavaScript-Free Front End

#209

I'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?

Can't imagine anyone that's tried intercooler.js would actually downvote. It's really nice and, in my opinion, totally addresses the author's concerns.

Re: A JavaScript-Free Front End

#210
post #109

> 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…

> But using less javascript is the hype today...

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/

Post reply on HN