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

161–170 of 215 posts

Re: A JavaScript-Free Front End

#161

Post by automathematics »

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?

You haven't seen how many tabs my wife has open. If you send her to a window, she's never getting back :)

Re: A JavaScript-Free Front End

#162

Post by mickael-kerjean »

cuddlecake wrote: post #145
smokeyj wrote: post #122

Earlier quoted context omitted.

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.

The ecosystem is even today the main selling point to rails

Re: A JavaScript-Free Front End

#164

Post by lhnz »

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

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.

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?

Re: A JavaScript-Free Front End

#166

Post by eeeeeeeeeeeee »

mrec wrote: post #84
eeeeeeeeeeeee wrote: post #51

Earlier quoted context omitted.

Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.

"people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is . There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance,…

I don’t deny any of those things. I think you’re reading way too much into my statement. I understand why people pick familiar tools and the cost of hiring and training people and getting up to speed on new stuff. It’s always a balance, and it’s why I don’t really like these posts that completely dismiss JavaScript and act like it has zero benefits.

I was on a team recently that only wanted to do Rails apps. They only wanted to make monolithic apps. Any mention of a more modular design would be met with derision. I don’t think this attitude is unique, though. And it’s really hard to overcome and see balance when the entire team clearly has no interest in changing or updating their skill set.

Re: A JavaScript-Free Front End

#167

Post by krapp »

hliyan wrote: post #8

This is totally true. We've recently started to discover this paradox ourselves: when styling and layout is all done via CSS, and JS + other assets are cached, HTML is just as light weight as JSON over the wire. As ashamed as I am to admit it, our newest innovation appears to be "multi-page apps"!

>We've recently started to discover this paradox ourselves: when styling and layout is all done via CSS, and JS + other assets are cached, HTML is just as light weight as JSON over the wire.

In other words, when the web is architected as intended, it works fine, even with javascript.

Imagine that. It's like the problem isn't javascript per se, but unnecessary complexity.

Re: A JavaScript-Free Front End

#168

Post by freeopinion »

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

...

> The Website Obesity Problem is not getting any better for the web at large.

These are both important points. But remember that 50MB of CSS stylesheets is still very obese and very complex. Replacing bloated JS with bloated CSS is of arguable value.

Just saying...

Re: A JavaScript-Free Front End

#169

Post by anthony_doan »

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 a demo for Texas and Liveview which show pretty good performance. I'm not sure if it is good enough performance but it looks promising.

Video for Texas: https://www.youtube.com/watch?v=NWgwUKfR8Xg

Video for LiveView: https://dockyard.com/blog/2018/09/12/liveview-project-at-eli...

Re: A JavaScript-Free Front End

#170

Post by yjftsjthsd-h »

lhnz wrote: post #164
yjftsjthsd-h wrote: post #147

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?

Why should I use his app?
Post reply on HN