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

111–120 of 215 posts

Re: A JavaScript-Free Front End

#111

Post by nicoburns »

onion2k wrote: post #14

Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd wri…

It's also possible to cache server-rendered pages offline with a service worker. Admittedly not many people do this, but there's no reason why they couldn't, and it would probably be smaller for a lot of sites.

Re: A JavaScript-Free Front End

#112

Post by gambler »

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

Personally, I try to avoid modal popups altogether. There is almost always better ways to structure things. The whole concept of "modal" UI doesn't map well to the "document" nature of web elements.

Re: A JavaScript-Free Front End

#113

Post by honkycat »

The very-immature Phoenix LiveView kind-of fits this use case.

It looks AWESOME and I'm excited to watch it mature over time.

Basically, LiveView is an Elixir library that allows SPA-style web page interactivity with server-rendered pages.

Re: A JavaScript-Free Front End

#114

Post by jypepin »

I had fun building our wedding website without any JS just to see how much I could push the boundaries of CSS and HTML. That was fun and a good learning experience. I'll now be able to build better apps _with JS_ knowing where it makes sense to push CSS/HTML and where it makes sense to use JS.

I recommend any front end engineer to go through that exercise, but it is not a good solution for real production systems.

Re: A JavaScript-Free Front End

#115

Post by roebk »

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…

This is not simply about modals. Using VoiceOver and Chrome I cannot access the pop up menu to navigate the site. These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing.

More specifically, no you cannot add keyboard shortcuts "with 0 rework". How are you returning the users focus to the active element before they opened the modal? The key is not to use an "arbitrary JS library for modal popups" and to use or create a modal library that has superior usability baked in. Sure, maybe there's a superior workflow than to use a modal.

For anyone that is interested MicroModal (https://micromodal.now.sh/) ticked a lot of boxes last time I checked.

Re: A JavaScript-Free Front End

#116

Post by lhorie »

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…

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

Re: A JavaScript-Free Front End

#117

Post by pier25 »

kabes wrote: 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...

I don't know, the hype is usually In React, Vue, etc.

Re: A JavaScript-Free Front End

#118

Post by Wowfunhappy »

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…

While I recognize a lot of the HN crowd blocks Javascript, the overall percentage of people doing this is absolutely tiny.

What is the case for making Javascript-blocking users a priority?

Re: A JavaScript-Free Front End

#119

Post by jasonhansel »

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

Re: A JavaScript-Free Front End

#120

Post by onion2k »

sametmax wrote: post #64
onion2k wrote: post #14

Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd wri…

> If only you'd written an offline-first PWA and used background-loading and prefetching with some intelligence to retry failed requests in order to deliver content before I actually need it this would have worked so much better. Then I would have waited too long to load the page the first time and give up.

The code you received the first time you load the app should be identical to the server-rendered version with a single additional script tag that loads a small JS file asynchronously. That script then progressively enhances the page to make it a PWA with features that take advantage what your browser supports.

Not enough developers build this way yet though because it's quite hard work. In my opinion the answer is to use what browsers are capable of; it should not be to ignore the browser and do as much as possible on the server.

Post reply on HN