Hacker News Reader

Comment by kh_hk | Hacker News Reader

For me 2012 was the year I stopped any frontend work at all. As I remember, things felt very easy and natural when all I had to do was output html using templates, write CSS and add some touches of javascript here and there, either using jquery or mootools. Maybe a websocket to display something coming from a process. Then there was backbone, history push state, more frameworks, client side rendering, meteor, and a lot of impressive stuff. Very impressive stuff that felt needlessly complicated and made me procrastinate every time I tried to learn it.

Nowadays, every time I look at a react codebase I feel certain emotions I can only describe as disgust. Maybe I have only seen bad codebases.

View on HN

I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What seemed to happen around 2008 onward is that the basic principles of the web were sort of simple, but then to do anything at a larger scale it got pretty crazy quite quickly, and so new architecture ideas came along to address that by people who were in the business of solving engineering type architecture problems.

For any site of inherently simple interactivity, it's always been as easy if not easier than it ever has, but now it's also more manageable if you know you're going to need to scale a certain way.

It doesn't necessarily take all that much before you can start to see the reasoning. For example, take a humble grid of products, each with their own add to wishlist button, and a profile preview button in the corner of the page that indicates how many things are on your wishlist. Pretty simple to handle, render the thumbnails with unique ids and make an XHR request that stores the data with your account. Update the wishlist total count however you would.

Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while.

Sorry for the book, I mostly wrote that to challenge myself to think it through, not to imply you couldn't think of how it would be necessary to componentize things.

I'm not particularly fond of React more than Vue or anything, except for the fact that they both allow you to define UI as collections of functional state machines when it's necessary to do so.

On the contrary, I enjoy a good discussion!

I do totally get the point of using a framework like React or Vue to manage state on a complex app. I do purposefully call them apps, because websites are a more general term. Hand woven javascript UI, even if it was using an utility framework like mootools could get out of hand pretty easily. I recall things like extjs that were also popular.

Following my own example, managing push state by hand was tricky. So I did buy in on the premise that an opinionated way of structuring help and more importantly state was necessary. But I have been consistently failing to learn any new frontend tool ever since. This was not terrible professionally, since I mostly do what most refer to backend or systems. But still it is a bit frustrating not being able to follow along. Maybe it would be easier if this was 'it' when I started learning as sometimes it's difficult to forget and relearn.

Speaking of React / Vue codebases, I have thrice tried to contribute some changes or fix a bug on different projects and the amount of boilerplate I had to go through felt completely unnecessary and overkill. Maybe the pattern on these never 'clicked' or I was very unlucky to stumble unto bad examples. It's very easy to dismiss something one does not understand as unnecessary complex so I am still open minded about it. The feeling of disgust when I see the many levels of inference, types and juggling state around for UX that I see as pretty basic persists, though. I like the result, I abhor the execution.

I would think that “feeling disgust” and ”being open minded” are mutually exclusive. So my impression from your post is that you are not being honest (to us or to yourself) about being open minded.

I do not see why these are exclusive: When I read the code, I can't control feeling disgusted by what I see. Specially how every base starts with an opinionated and strong "this is how it's done" style, just to devolve into copypaste and hacks because someone didn't understand state, reductors, types, dispatchers, ... but I am open minded about acknowledging that the problem might be mine, be it because of stubborness on not getting it, or being extremely unlucky on what projects I stumble upon.

> Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while.

I've done this many times, using plain-old jQuery and server-side rendering, and it really isn't that hard. The "conventional" way is to (of course), render the preview(s) with classes or data attributes on the updatable elements s.t. you can quickly identify the elements that need to change (say $('.wishlist-count').text(updatedCount) for the sake of argument).

For more complex things (let's say you need to be able to insert a complicated, but slightly different, object in the wishlist, for example), you can render a template into the page, dup it on wishlist addition, and populate the variable data in any number of different ways. You can even create JS objects that encapsulate this kind of logic (e.g. Wishlist.add(itemNumber)) without much additional effort. No framework required.

Now, I grant you that when you need to do this for many different kinds dynamic elements that all interact in different ways, or when you need to absolutely guarantee minimal re-rendering, you might want to jump to a framework. But I still feel that most front-end people these days instinctively rule out simpler approaches that would work just fine, because they're prematurely optimizing. Or worse...because they simply don't know anything other than React.

The thing that bothers me about React and other frameworks is the look of the code. React components look like every other React component. There are few signals of “hey, I’m a dropdown” or “hey, I’m a table” due to caked on layers of abstraction and indirection. One thing I like about serverside code is that a tree processor looks like a tree processor while a state machine looks like a state machine. I don’t have to think hard and can use pattern recognition

Maybe you will like https://svelte.dev/, I find it more close to good old html. For example, a component that is not interactive is basically an html file with an <style> tag and some html markup.

I feel the OP. It is not about HTML alone. It is about the lack of understanding of the full picture. About the fact, that you cannot rationalize everything. That everything is three layers away.

The problem with the OP feeling (and mine) is that there are shoulders of giants. You either stand on them or not. If you are not, you start on much lower level of features ;)

Makes sense and I agree. For simple things I still do vanilla js. As soon as I need to re-use components or shared state between pages I go with sveltekit.

Building front end apps has become more complex than it used to be 20 years ago to effectively output the same html.

Granted there is a level of interactivity that is different for the complexity, mostly I look forward to the grand complexities of todays frameworks to continue to simplicity and be approachable.

As soon as you need to 1) render a list of widgets asynchronously, 2) update widget #182 of 250 without re-rendering the whole widget tree, you start to realize that these front-end frameworks have solved the problems that we used to spend hours writing fiddly and confusing jQuery functions to address.

No doubt.

Still things get more complex before they get streamlined.

Frameworks like svelte, vue, and even flutter to a degree feel different than react when putting together similar experiences in some cases.

Same here, I went back to native desktop development, and nowadays I am mostly focused on backends in what concerns Web development.

If I need to do WebUI stuff on my own, it is classical vanilajs with SSR in Java/.NET frameworks.

React is awesome, but there is a learning curve to using it well, moreso since hooks came out.

Being able to define your view as a pure function based on your state is a very powerful.l abstraction, but it took me about 2 years to learn to wield it well.

It was much the opposite for me.

I started building websites amaterishly from about 1995, and professionally from about 2001, and always hated how complicated and messy my code became any time I wanted to build rich functionality (i.e., a web-app rather than a website).

That first changed for me when I discovered ExtJS (now Sencha) in 2007, then later Angular and finally React in 2017.

These days I work almost daily on a React web-app I've built for displaying realtime weather/climate data for farmers, and it continues to be a very pleasing codebase to work with, more so than any I've worked on before.

Not sure what you find 'disgusting' about a function that returns HTML; if anything it is more 'natural' than the templating and jQuery amalgamations of the past.

> Maybe I have only seen bad codebases

Maybe there are no good react codebases because it encourages bad code.

The whole concept of having both code and structure definitions in the same file is just flawed at its core. Like deliberately writing all your js in html script tags for some reason, except with functional-style syntax that just makes it look more cryptic to newcomers for no reason at all.

Reply on news.ycombinator.com