Live data from Hacker News

A JavaScript-Free Front End

dev.to

211–215 of 215 posts

Re: A JavaScript-Free Front End

#211

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 completely agree with you, which is why I think that telling people to "just install next.js" is a terrible advice. If they are JS devs, experienced in next, sure, go right ahead, but I don't think that's the case here.

I'd be fine to just use Rails for something like that since I'm quite familiar with Rails, but I would never recommend it to someone who doesn't know it.

Re: A JavaScript-Free Front End

#212
I think this ignores one of the main benefits of JS based page rendering.

In the days where I worked on PHP apps, all rendering was done on the server, and that came at a great cost regarding server side processing and the complexities of peak load times, along with some pretty hairy test cases.

With everything rendered in js, you are mostly just transferring static assets, so the browsers are doing the heavy lifting for you. The only things that end up taking up server CPU cycles and system memory were API calls that are easy to test, debug, and optimize. Also, those API calls can be cached, and become static assets for high traffic apis such as ones accessed on the front end.

If you do it all on the backend, you are doing all the rendering work, and it is hard to split off and optimize processing time for things.

Finally, for testing, it is really easy to unit test an API, and for javascript frontend work, there doesn't seem to be the code regression type bugs that are so time consuming, but when you mix the data api stuff with the front end rendering, unit testing becomes a big mess.

Bloat needs to be thought about, especially for limiting bandwidth, but just for curiosity, I checked out my own website which was using React and a bunch of libraries, and it was only 500K. This is about half the size of the banner image on that article. Some libraries are much larger than React, but going JS free and losing the power React gives you doesn't seem like a good trade off.

Of course if you get some happys from being an ultra-purist, then I get that, and that is priceless. From a practical perspective though, this seems misguided.

Re: A JavaScript-Free Front End

#213
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…

Agreed on the modals, but this is a non-unique problem. Accessibility just takes work, whether it is fixing JavaScript libraries or supplementing CSS only solutions. And since performance and accessibility often suffer together at the hand of these JavaScript libraries, it is encouraging to see that there are other options for building good user experiences.

Re: A JavaScript-Free Front End

#214

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 completely agree with you, which is why I think that telling people to "just install next.js" is a terrible advice. If they are JS devs, experienced in next, sure, go right ahead, but I don't think that's the case here. I'd be fine to just use Rails for something like that since I'm quite familiar with Rails, but I would never recommend it to someone who doesn't know it.

> If they are JS devs, experienced in next, sure, go right ahead, but I don't think that's the case here.

The author is clearly experienced in UI development. The app was already written in React/Redux. So honestly, yeah, just install next.js and fix your routes.

This solution would be a complete non starter for any professional project in terms of accessibility - there's a few issues screen readers would run into with this. Not only that, but good luck getting other developers to sift through your spaghetti code.

But the main thing is, the authors goals are somewhat pointless. If you don't want a SPA then just use jQuery. The author ended up using plugins anyways so the whole story was aimed at people who don't know front-end but latch onto this idea of javascript is baaad. Don't be that guy.

So to recap. If you don't know javascript, and you don't want to learn the standard tooling - please don't roll your own framework and blog about it.

Edit: looks like someone already commented this on his blog. This is all you need to know: https://dev.to/isfotis/comment/9c7k

Re: A JavaScript-Free Front End

#215
post #72
post #28

I like the slogan "JavaScript-free"! Finally something to rally around. I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would be nice if there were a slogan that included these. Looks like it actually does use JavaScript for the "select2" case. This is exactly the case I'd be happy to special case. edit: added paragraph

http://vanilla-js.com/ It's got a badge and everything.

This is cool. But it needs to be updated for ES6. The "Code Examples" could look even better now.
Post reply on HN