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

141–150 of 215 posts

Re: A JavaScript-Free Front End

#141

Post by gambler »

roebk wrote: post #115
gambler wrote: post #112

Earlier quoted context omitted.

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

>These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing.

The same can be said about any JS library that interacts with page controls.

The wast majority of modal dialog implementations on the web do no follow the standards you're referencing. Do you routinely criticize websites on this basis, or is this criticism only reserved for ones that use vanilla HTML+CSS for core functionality?

>More specifically, no you cannot add keyboard shortcuts "with 0 rework".

Yes, you can. 0 rework != 0 work. Anything that unchecks that checkbox on Esc will close the modal. To implement that you don't need to change the structure of what you've already done. Progressive enhancement.

>How are you returning the users focus to the active element before they opened the modal?

Focus management has absolutely nothing to do with where the state of the modal is stored. You can implement all of the usability features you want on top of Checkbox + CSS solution with the added benefit of not screwing everyone who can't run your scripts or completely breaking the website for everybody if something in your JS gets broken.

Re: A JavaScript-Free Front End

#142

Post by cuddlecake »

yjftsjthsd-h wrote: post #125
Wowfunhappy wrote: post #118

Earlier quoted context omitted.

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?

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.

Re: A JavaScript-Free Front End

#143

Post by Can_Not »

lol768 wrote: post #137
Can_Not wrote: post #135

Earlier quoted context omitted.

> You know what happens if the same thing happens with most SPAs? It throws away my unsaved data and puts me back on the starting screen. This is just bad design though. Obviously the dust isn't settled on the whole html5 technology yet, but for anyone who is wondering how to make an SPA more resilient to network instability, the solutions are: axios-retry, idempoteny PATCH/PUT, service workers, basic error handling,…

>This is just bad design though. Obviously the dust isn't settled on the whole html5 technology yet, but for anyone who is wondering how to make an SPA more resilient to network instability, the solutions are: axios-retry, idempoteny PATCH/PUT, service workers, and basic error handling. Thing is, you get proper error messages, the ability to retry, warnings if you're about to repeat an unsafe operation etc out of the…

I've seen pure server based applications neglect all of those things, including destroying your input on errors, so it's not really helpful for anyone who actually needs an SPA.

Re: A JavaScript-Free Front End

#144

Post by cuddlecake »

lhorie wrote: post #116
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?

I'd reckon it's easier to share data between parent and child, than between completely different pages.

Re: A JavaScript-Free Front End

#145

Post by cuddlecake »

smokeyj wrote: post #122
tomca32 wrote: post #108

Earlier quoted context omitted.

> Author could have installed next.js and called it a day. Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed. Javascript apps are tremendously complex, why would do this if you don't have to?

Imagine you have a team of rails developers and you're asked to create a simple portal. Rails as a tool may be "overkill" but what does it matter? If you already know Rails I'd say use that. If you only knew ruby then reaching for rails would be overkill. But if your business requirements need the features of Rails, learn rails instead of rolling your own framework..

I am genuinely curious, what kind of Rails features can satisfy which business requirements?

I thought people use Rails mainly because they like it or are thrown into a team that already uses it.

Re: A JavaScript-Free Front End

#146

Post by rhinoceraptor »

Can_Not wrote: post #143
lol768 wrote: post #137

Earlier quoted context omitted.

>This is just bad design though. Obviously the dust isn't settled on the whole html5 technology yet, but for anyone who is wondering how to make an SPA more resilient to network instability, the solutions are: axios-retry, idempoteny PATCH/PUT, service workers, and basic error handling. Thing is, you get proper error messages, the ability to retry, warnings if you're about to repeat an unsafe operation etc out of the…

I've seen pure server based applications neglect all of those things, including destroying your input on errors, so it's not really helpful for anyone who actually needs an SPA.

Yep, how many times have you seen a web page say tell you not to refresh the page to avoid losing your progress.

Re: A JavaScript-Free Front End

#147

Post by yjftsjthsd-h »

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.

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)

Re: A JavaScript-Free Front End

#148

Post by x3ro »

MarkMyWordsMan wrote: post #131

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…

I'm still trying to grasp why these discussions so quickly spin into extremes. The author clearly states her intent in the first paragraph:

> With the new version I wanted to prove that it was possible to deliver an amazing user experience with a great design while drastically reducing the complexity of the code, maximizing reliability, and minimizing the cost to the end user.

She goes on to show us what she did, where it worked and where it didn't. The most important points I take away from her article are:

1. It's quite possible to build nice-feeling (YMMV), non-single-page web-apps without (a ton of) JavaScript

2. Critically evaluate if you need the complexity that an enormous JS framework brings

> You probably don't need a "Progressive Web App." Seriously evaluate if your app needs such complexity.

This has nothing to do with FAANG. Nobody disputes that there are use cases where it's a really good idea to use React+Redux+Jest+Enzyme+XYZ et al. But _maybe_ (and in my personal experience, in projects significantly smaller than Amazon.com, often) you simply do not need that amount of additional complexity and challenges.

It'd be so nice to just accept that the author provides an interesting data point (it can work without JS) in a community strongly biased towards starting projects by importing ~1000 node modules.

Re: A JavaScript-Free Front End

#149

Post by hombre_fatal »

lhorie wrote: post #116
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?

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.

Re: A JavaScript-Free Front End

#150

Post by MarkMyWordsMan »

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…

kabes is to the point! It is fashionable to hate on modern front-end frameworks these days.

Imagine the OP grows their platform/company, hires a bunch of devs, what a nightmare that would be to keep avoiding JS and build on the product.

All so just because using JS is so mainstream, ugh.

Post reply on HN