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

191–200 of 215 posts

Re: A JavaScript-Free Front End

#191

Post by c22 »

gambler wrote: post #112
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…

You can trivially add keyboard shortcuts to this solution after it's implemented - with 0 rework. Moreover, the is absolutely no guarantee that an arbitrary JS library for modal popups will have better usability. And I have yet to see one that will not fail if I block JavaScript, creating horrible user experience for everyone who does so. Funny how usability concerns go out of the window when NoScript/uBlock users ar…

> block JavaScript

How did we even get here? I remember when we used to hide javascript inside of comments to support user agents that didn't speak it.

Re: A JavaScript-Free Front End

#192

Post by c22 »

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.

Some "interactive" websites have to use javascript, it's true, but it always seems tragic when a site that doesn't really need to requires it anyway. Isn't there something appealing about a platform where millions of strangers can converse and publish information without needing to fully trust one another?

Re: A JavaScript-Free Front End

#193

Post by mercer »

Geee wrote: post #156
mercer wrote: post #104

Earlier quoted context omitted.

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

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

I'd use websockets if that was an issue. That said, Trello is a good example where I do agree a web app is a great solution.

Re: A JavaScript-Free Front End

#194

Post by c22 »

hombre_fatal wrote: post #149
lhorie wrote: post #116

Earlier quoted context omitted.

Just to play devil's advocate: why use a modal in the first place instead of just opening a new page?

Less jarring to the user, creates the UX where the user knows their state is still there once they dismiss the modal, less commitment overhead, etc.

I find the opposite is true. I can't count the number of times I've accidentally closed a window or backed out of a page using a modal where the semantics were unclear or the comically tiny 'x' was hidden below mobile-Chrome's sliding address bar on a page that was too short to scroll.

Re: A JavaScript-Free Front End

#195

Post by Mirioron »

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.

>Either you trust me, or you don't.

Can I sue you if your website serves me malware? Because that's the concern.

Re: A JavaScript-Free Front End

#197

Post by ngrilly »

cmclaughlin wrote: post #86

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?

Re: A JavaScript-Free Front End

#198

Post by squish78 »

c22 wrote: post #194
hombre_fatal wrote: post #149

Earlier quoted context omitted.

Less jarring to the user, creates the UX where the user knows their state is still there once they dismiss the modal, less commitment overhead, etc.

I find the opposite is true. I can't count the number of times I've accidentally closed a window or backed out of a page using a modal where the semantics were unclear or the comically tiny 'x' was hidden below mobile-Chrome's sliding address bar on a page that was too short to scroll.

It seems like the modal is often abused as an anti-pattern, where it's not even clear if you are still on the same page because the content is almost entirely concealed/darkened. Reddit desktop is an example. Modals with multi-page length scrolling content is just absurd

Re: A JavaScript-Free Front End

#199

Post by Sir_Substance »

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.

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

#200

Post by lhorie »

zachguo wrote: post #159
lhorie wrote: post #57

Earlier quoted context omitted.

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

Some things like the radio box trick are hacky, I agree, but many things are not. Personally, I like to strike a balance between old-school techniques and new technology (e.g. use CSS for hovers instead of instagram-style DOM manipulation via JS)

To me, this whole thing about JS-Free is a backlash against overdoing things in JS, and it's as good time as any to rethink today's status quo, especially in regards to how many babies we have thrown out w/ the bath water when adopting JS-first technologies.

Post reply on HN