Hacker News Reader

I am also a classic web developer, still using vanilla javascript and trying to do as much as possible with just html and css. I feel I can solve any problem fast, quick and with minimal amount of code and bugs. For the recent years I have hired a few javascript developers and a common pattern I see is that the reason why they want to use overcomplicated toolset, is because this helps improving their CV so they are easier to sell. CV building is a thing, and developers also want to stay relevant in the future.

For example I went through software developer job listings in my area. Of 100 listings, 40 of them are React specific, 2-3 Angular while maybe 5 mention any kind of frontend development like html/css/jquery. The rest is classical back end positions. There is a HUGE demand for frontend expertise these days.

If you as a consultant want to sell yourself as a kickass rockstar frontend developer, you want as much React experience as possible on your CV. Some will even turn you down because of the fear of damaging their CV by just doing vanilla javascript work.

> still using vanilla javascript and trying to do as much as possible with just html and css.

Thank you. As someone who only allows JS to run very, very sparingly (and even then only on sites that are, for one reason or another, actually indispensable to me), I appreciate this very much.

If a site requires JS to work, and if that site is something that is optional for me, then I won't use that site.

Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.

React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it.

What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance

Yeah I dont know about that. If you've ever had to deal with optimizing event delegation and updating the DOM without causing massive repaints you'd change your tune.

Not really, at least in my experience. The re-binding really isn't the same as the jquery way. React reuses the same event handlers, how it's implemented is another story and not really important anyway. The other issue is the fact that in the old way it's implicit that there's a mix of server and client side rendering. Say you have a grid of data that was rendered server-side. Then you update a row, which posts to an api endpoint and you get a reponse that represents your new row. At this point there's only a couple of ways this could be done:

1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements.

some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away.

I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.

Ah, good old Resume Driven Development. I've seen it and even done a little of it.

> I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much;

This is, in turn, is a weird mindset. Are you suggesting that web developers are somehow unique in the software development space? Here's a hint: they aren't. The problems that web developers have to solve are relatively unique to the platform. When is 1MB of code a lot? This is not amount of code written, this is amount of code used. In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat? Because it doesn't have to be downloaded over HTTP like javascript. That is a unique feature of web development. What do you think would happen if developers around the world started complaining about using `numpy`? It's the same thing with libraries like `react`: they have no credibility because `react` is useful. It has nothing to do with web developer mindset, everyone wants to bring in libraries that make their lives easier.

>In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat?

Because some random Joe Schmoe can't replace numpy with a few lines of vanilla Pyton.

Because numpy has a governing organization and isn't just an arbitrary library some unknown developer dumped on NPM.

Because numpy is over a decade old and isn't any in danger of being superseded on the basis of not being fashionable.

Literally none of those things apply to React though.

  > I wonder if there is a common
  > mindset that the majority of
  > web developers have which
  > causes them to love
  > overcomplexity so much

We don’t love complexity, we love ease. The complexity is a side affect of us trying to make our job easy by `npm install`ing various tools/libraries/frameworks :)

Another problem is the web is inherently complicated, and people expect more and more from the web. We’re still working out how to best manage the complexity and increased demands.

Taking on a huge amount of dependencies only (potentially) makes your life easier up front.

You now get to experience all bugs and side effects for all projects you now took on "due to ease."

You now effectively maintain all those projects, instead of your own. You cannot go to your customers and say "well this library isnt working so neither is our website, and we can upgrade without it."

You also cannot go to your customers and say "well instead of using a popular library, we used our own and it broke and so did your site"

And more importantly, NIH leads to on-boarding issues. Many, many people are React/Angular/Vue developers, but how many are $INTERNAL_RECREATION_OF_REACT developers? By creating a new framework, you waste money (not just on reinventing the wheel and fixing bugs in your new wheel, but also on having every new-hire take even longer to get productive)

Code that you've written also tends to be code you have an understanding of, and thus much easier to debug than a maze of third-party dependencies.

The extreme aversion to "reinventing the wheel" leads to things like left-pad.

> I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent.

Is this really unique to (frontend) web developers? I've heard plenty of stories of people building tangled webs of microservices when a monolith would be fine, using Kubernetes to run their weblog, using Hadoop with small datasets, etc.

I once worked with a guy who, after looking at a solution provided by our team that not only worked but was fast and efficient, said, “This can’t be any good. You don’t have enough code.”

He was in a leadership position.

This way of thinking isn’t restricted to our industry. I see it in other areas as well. People naturally equate complexity with quality and actually have a hard time appreciating the beauty of a well-designed, well-thought out, efficient system. Why that is is beyond me.

> People naturally equate complexity with quality

Which is weird because, generally speaking, higher code complexity is a signal of lower quality.

It goes into why we need design systems, software architectures, libraries at all? Because of communication and managing complexity. You give 5 developers one single set of requirements, their approach to the problem likely to be drastically different. Could their solutions be effective? Very likely to be. But that's not large projects are about, they are about continuity of the projects without locking into developers.

For developers want to solve a problem quickly, you are correct - and more power to you because no one else (mostly) can understand your code. Job security FTW there. I think most of companies starting to realizing they can't keep people like you very long. You are both capable and stubborn (most likely). That's why job market is shifting towards mediumly skilled team and process oriented developers. Hope that makes sense.

> [1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough"

I've said this in code reviews a few times. In ever case, it was because someone was using some construct that would have been needed in older Javascript versions, but was no longer necessary in whatever deployment we were supporting as a minimum. Sometimes it was from taking old Javascript conventions into Typescript. In ever case, the original code was a workaround for old bugs.

Can you cite an example?

Did you mean to write `What's so "exciting" about doing more with less?` I think the answer is obvious...

More on topic I think more context is needed on your anecdote. Was you developing a small tool that's likely to balloon into a suite of tools etc? There may have been a variety of other factors to consider whether it may be worthwhile investing into a framework in the long term

I'm not saying that your sentiment isn't at least a little true - but creating complex modern web applications is hard and frameworks CAN be the right decision depending on requirements.

RE: "not modern enough"

I often hear the following versions: "that's not the current paradigm" or, "that's not recommended"

Those should not be ignored, but they should be immediately followed up with by "why?" because understanding why the old paradigm didn't work, or why something isn't recommended, is important knowledge to have. If you tune out when someone tells you no, without asking why, you haven't started learning yet. There might be great reasons for why the current paradigm is actually preferred, or why that code you wrote is actually really bad because a single edge case that just happens to be severe enough. Until you ask why, you won't know, and your decisions will not be informed decisions.

The sad part is, those are the answers to my question "why"...

> "that's not the current paradigm" or, "that's not recommended"

When I see these words, I think these are followers. They don't truly understand why they are doing what they're doing, but "everyone else" is doing it, so it must be good.