Why does this site require JavaScript?

It’s a question I see all the time on Hacker News forums. Whenever someone posts a Show HN site that is implemented in React/Angular/Vue, this question shows up near the top of the comments.

So, I thought I’d sit down and reflect on my own projects — current and past — and try to answer this question.

JavaScript is ruining the web

Let’s be clear. As a general rule, I don’t like JS-heavy sites.

As an example, the Hacker News UX is _s_o much better than the Reddit UX — especially on mobile. Reddit takes forever to load. HN loads almost instantly. Clicking a link or the back button in mobile Reddit does absolutely *nothing* for several seconds, which is a regular source of confusion. In HN, links and back navigation just work instantly, because they’re plain ol’ hyper links.

Reddit does a lot that I simply don’t give a crap about. It has lots of mess in the side-bar that I never look at or care about. I think it has live notifications of responses to my posts or whatnot. (In my experience, live-updating features almost never need to be.) Reddit could be a *really* basic categorized, searchable forums site, written as a traditional MPA, and (to me) it would be a huge improvement.

In general, I don’t want your site to “live update” on me. I don’t want gmail to live-update on me. I don’t want your news site to live-update on me. I don’t want your stupid popups or slide-in notifications. I don’t want your animations. I don’t want much of anything other than content displayed in a clear, readable, and undistracting format.

To summarize, I prefer really basic HTML and CSS sites to just about anything else. SPA sites are often slow, resource-hogging, navigation-breaking, mobile-failing, janky turds. It’s harder to produce such crap if your site is just basic HTML + CSS. Plain HTML and CSS is cacheable. Its behavior is predictable(ish) and consistent(ish) across other plain HTML/CSS sites. It is fast on all devices. It behaves as expected. Right-clicking a URL just works.

And yet…

My sites are all JS heavy

WTF?! I’m such a hypocrite, you say.

Well, yeah.

Why is this?

Here’s a smattering of programs I’ve written in the past few years: webinars, live-chat, live notifications, discussion forums, complex forms with conditional live-updating regions, rich site editors, lots of list pages that are modified in-place and need to retain order/filter state, a rich medical survey builder, an event-driven system that controlled a shipping terminal in near-real-time (camera systems, gate arms, RFID sensors, OCR camera systems, digital signs), and more…

Hopefully you’ll agree that most of this list justifies the use of rich front-end frameworks, so maybe I get a pass? That said, let’s see how JS might creep into a simpler site.

The sad tale of how JavaScript creeps into simple sites

Most of my applications start out relatively simple. It is tempting (and often I succumb to the temptation) to start them without any real front-end architecture. But with time, their complexity grows. This simple form now has a section that should conditionally show/hide based on the user’s entry. Oh, and the list of prices at the bottom should live update live based on their input in field 5, etc. Every single seemingly simple screen grows complex with time. As their complexity grows, I begin to wish I had a better way to manage front-end complexity, and I begin to regret not starting out with a solid front-end architecture.

Here’s a real example. One of my projects has a screen that involves mostly static content (a lesson), with a discussion thread at the bottom for students and instructors.

Cooleo.

This could be done in traditional web fashion with a full-round trip required upon submitting a comment.

But then you’d likely lose your scroll position, and if the screen also includes a partially filled out quiz, you’d lose your quiz state when posting a comment. OK, so we can sprinkle a little AJAX in there. No need for heavy ol’ React or anything like that. Problem solved.

But then, the client wants a running count of the number of comments and number of unique discussion participants to show up at the top of the comments section. No problem. We can just slap that in there. Just a few more selectors. Problem solved.

But then, the client wants the discussions to live-update as people chat. Hm. Well, we can still do that, but now our front-end logic is getting messy. It’s being rendered via Rails on the back-end, but being updated live on the front end, so it needs to get HTML snippets and put them in the right places… Messiness ensues. OK, so let’s just make that bottom discussion section a little mini-React or Vue app or something. Problem solved.

But then, the client wants the discussion stats to also show at the top of the page, above the lesson content. Well, crap. That means updating part of the page that doesn’t belong to React. Now, should we move the lesson content down into the React component? Should we just be hacky and update the discussion stats via a DOM selector? Mergh… React all the things!

One way to rule them all

Having one way to do UI is better than having multiple ways. Having some UI served up from the back end and some generated on the front end gets messy fast. Having all UI on the back-end is limiting for complex applications. Moving all UI to the front end allows you to handle any amount of growing complexity while still having one way to write UI.

React is a superior development experience to most back-end alternatives

The previous reasons are why I think JS worms its way into most projects I’ve worked on. But in my current project, there’s another reason. I find that React provides one of the most pleasant means for building UIs. If the back-end was written in a functional language like Clojure, things might be different. But my current project is Rails.

Here’s a rundown of some reasons why I prefer React vs erb/Rails:

- Functions are better than partials- Functions are better than blocks- Explicit imports are better than implicit ones- MVC controllers complect multiple independent actions (e.g. index, show, update) into one place- Traditional MVC apps complect data validation, manipulation, and storage with UI concerns- Immutability is easy to reason about, and is not really encouraged by Ruby/Rails, but is largely encouraged by React best-practices

Separation of API from UI is nice

I hinted at this above, but it bears its own segment. Writing simple back-end APIs, and then leaving the UI up to the (various) front-ends creates a nice separation of concerns. It also gives you an API which is a benefit in its own right. You can choose to expose this to the outside world, if you want. You can write a native mobile app. There are quite a few things that become much simpler if your application is architected this way.

Conclusion

Why does this site require JavaScript? There are many reasons. Arguably, it shouldn’t. Arguably, the team should have said “no” more forcefully to complex features that really don’t enhance the UX.

But even so, some applications are just complex. Often that complexity isn’t obvious to the casual consumer. Front-end frameworks help tame front-end complexity. (Duh!) Also, some backend technologies just suck, and that suckiness can be mitigated by moving the front-end to a less-sucky technology without requiring a rewrite of your entire application.

So the next time you begin to criticize a site for requiring JavaScript, hopefully, you’ll pause and think, “You know, this probably isn’t as black and white as I think it is.”

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!