Hacker News new | ask | show | jobs
by gherkinnn 1803 days ago
I like most of React and am strongly against writing anything akin to an SPA in vanilla JS. (Whether or not an SPA is the right approach is debatable but besides the point)

And yet this article is disingenuous. The OPs target can be achieved using CSS alone. In fact, quite a lot of things can be done quite well in vanilla JS and CSS.

This works well to some degree. Then I found it to fall apart.

- Those BE devs now forced to write FE in React|Vue|* and hate it so much that they've never learned it, won't learn a vanilla stack either. Especially not CSS. That's just for colours. Or something.

- Most vanilla approaches I worked on relied heavily on the correct ordering of HTML elements with the correct classes for something to work. There's little to no encapsulation. Only copy and paste. It's also immensely brittle.

- You can add some simple encapsulation, but the easier way is to brute force some imperative mess. Close ticket. Open next. Velocity is high.

- The next step is to build your own framework. But chances are it will be worse than any 3rd party solution.

- A huge advantage of 3rd party libs is that there's zero chance of some ticket specific code to erroneously make its way in to the framework. Silos aren't always bad.

- Onboarding new devs is hard. There's probably no resources at hand.

- At this point you've tied yourself in to knots and the actual problem, your product, isn't even close to being solved.

It takes less than an hour to have a fast React|Vue|* application off the ground. Everything you need to build the product is in place. And with some care, it will remain fast. Alternatively, Ruby on Rails and friends work just as well.

However, wasting endless hours reinventing a worse wheel is unproductive.