Hacker News Reader

Comment by andykx | Hacker News Reader

I recently decided to, for the sake of practice, build some single page apps using Vanilla JS. It was such a pain. Maybe some of it is due to my relative lack of front-end JS experience, but I found it nearly impossible to avoid duplicate code. I’m interested to know how people architected apps like that before. I was under the impression that SPAs were not nearly as common before frameworks like React.

View on HN

There where other toolkits before react, Dojo, MooTools, YUI each had their pros and cons. The problem was they where all fiefdoms similar to how Angular is. Where React really hit while the iron was how was that the whole JavaScript build and packaging system was moving to npm and react was one of the first sane component models available in that ecosystem. Unlike the previous attempts React did not try to be all things to all people, it was laser focused on being a component model and life-cycle. You got the rest via a plethora of options via npm install.

As a side not React also bucked what was the sage wisdom of the time which was, don't mix templates with code via the introduction of JSX. This came from the very real and sage pattern of separation of concerns but somewhere along the way we confused separations of technologies with separations of concerns. If a piece of CSS, a piece of HTML and a piece of JS are all dealing with the same black box concern and are not reusable outside of that black box, separation of technologies (i.e separate files for each) only serves to add complexity to the solution as it abstracts them away from each other, forces the need to resolve their interdependence and obfuscates the ability to quickly get an entire overview of the black box.

I wasn't thinking necessarily about pure vanilla JS, though that's certainly an interesting experiment that would lead to a better understanding of what something like React actually does. I was thinking about choosing the right tool for the job or scale of the job. If what you're definitely doing is an SPA, then you should probably assess how the nature of the application relates to the tools you'll choose. For many smaller things though, I'd doubt the necessity for an SPA at all, and vanilla JS would likely suffice. Considering that React is largely just one piece of the puzzle, it can easily be replaced in most cases by vanilla JS I'd think.

> nearly impossible to avoid duplicate code

Do you think duplicate code bad, no matter the case? I'd like to hear your thoughts.

Personally, I don't mind a bit of duplication and difficult coding if I can avoid a juggernaut like React, but I also don't mind simpler visual UIs. I actually prefer them over the complicated SPA that tries to look and feel like a native application, because it never works. There's this "uncanny valley" between native application UIs and SPA web apps which try.

Sure they were, you just organize the code in components in server side frameworks.

You get a way to organize your server side code, CSS, JavaScript and flavour of Web API of the month (SOAP, REST, gRPC, WebSocket, ...).

Naturally reusing components across frameworks isn't that easy, but the same problem also happens across React, Angular and what have you, unless you make use of WebComponents, but that only works if targeting the most recent browsers.

Reply on news.ycombinator.com