Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A JavaScript-Free Front End

dev.to

Post reply on HN
Print view View original

151–160 of 215 posts

Re: A JavaScript-Free Front End

#151

Post by khalilravanna »

jasonhansel wrote: post #119
roebk wrote: post #87

It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users. Be sensible and use JavaScript when it's appropriate. Pl…

Also: be sensible about accessibility when writing JavaScript SPAs. If your page consists entirely of nested s without any semantic markup, you're going to have problems (and perhaps risk a lawsuit).

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.

Re: A JavaScript-Free Front End

#152

Post by cuddlecake »

cuddlecake wrote: post #142
yjftsjthsd-h wrote: post #125

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.

You don't have to argue why you don't trust me, when I'm arguing that I'm not responsible for negative impacts in the case that you do not trust me.

Re: A JavaScript-Free Front End

#153

Post by jimjimjim »

cuddlecake wrote: post #142
yjftsjthsd-h wrote: post #125

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.

ok, i don't.

Re: A JavaScript-Free Front End

#154

Post by NightlyDev »

I totally agree that js is used way too much and dependencies are often included without ever considering the consequences.

But Javascript itself isn't bad. Just use it when it makes sense, and minimize it. Remove any dead code so phones won't have to spend cpu and data on it.

Re: A JavaScript-Free Front End

#156

Post by Geee »

mercer wrote: post #104
Geee wrote: post #43

Earlier quoted context omitted.

The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.

The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections. In some cases, even sending the entire HTML document and diffing on that using morphdom (because redrawing does bring noticeable cost rather quickly) was a viable strategy even compared to the most optimal json payload. I'd very much like to see some examples tha…

It's not the payload size that matters really, but the latency of requests which you have to wait between interactions, making the UX synchronous and slow.

Good examples are, well, almost any modern and popular app. Like Trello for example. Users spend lots of time on the same page making micro-interactions, creating cards, moving cards around, adding tags, etc. You want to make the in-app experience as flawless as possible in these types of apps, and the initial JS size doesn't matter so much especially when it's cached. There's also lots of shared state and you might be saving multiple things on the server at the same time or uploading multiple files in the background while editing other parts. You might want to store data offline and sync later to the server. Once you have decent complexity, JS app with framework such as React help a lot.

Re: A JavaScript-Free Front End

#157

Post by oh_boy »

roebk wrote: post #87

It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users. Be sensible and use JavaScript when it's appropriate. Pl…

Totally agree on your statement. It's not possible to build modern solutions that are accessible without using some JavaScript. It's always a matter of where you want to go. And it's easy to spare e.g. modals. The question is just if you can solve user experience issues with just HTML and CSS for all use cases.

On the other side, there are more solutions built into HTML and CSS one thinks. In your particular example, you can use the HTML dialog element and get built in keyboard and focus management (still requires a polyfill for many browsers).

Re: A JavaScript-Free Front End

#158

Post by kremonte »

khalilravanna wrote: post #151
jasonhansel wrote: post #119

Earlier quoted context omitted.

Also: be sensible about accessibility when writing JavaScript SPAs. If your page consists entirely of nested s without any semantic markup, you're going to have problems (and perhaps risk a lawsuit).

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 exists, but is not _particularly_ worthwhile for accessibility: Too much of the web lacks these tags, so most common consumers of this nature (scrapers, screen readers, content summarizers) use other, often AI-based, strategies to tag content semantics.

Re: A JavaScript-Free Front End

#159

Post by zachguo »

lhorie wrote: post #57
zachguo wrote: post #44

What JS does can be reduced to several things: - storing states, and conditionally passing states around - toggling things on or off - element reuse - dealing with events - ajax Unfortunately it's unlikely HTML & CSS would support all these.

The paradigm shift here is that most of these things would be done in the server using traditional techniques: ajax, events, state are all handled via form submissions. The only things in this list that are really "frontend-ish" are element reuse (which, for styling purposes, is accomplished via CSS methodologies) and toggling things on/off, which in the CSS-only corners of the web is accomplished using a radio box C…

We all knew these tricks and started from there back in the day. Don't you think they are way too hacky? and cause too many page refreshes? Have you ever maintained codes mixing server-side templating and JS scripts?

And there are so many edge cases popping up so that you have to use JS anyway. Then you may ask why don't I use JS for everything then?

JS is inevitable no matter how you and I hate it. "JS-Free" only makes sense for simple presentations.

Re: A JavaScript-Free Front End

#160

Post by crooked-v »

mrec wrote: post #73
crooked-v wrote: post #67

Earlier quoted context omitted.

Form posts to the server, just like the old days. Of course, then you need a full page reload every time you edit something.

Not necessarily a full top-level page reload. You can POST to an iframe.

If you want to see the final status of the submission without JS, you still need at least part of the page to visibly reload.
Post reply on HN