[nicoburns]

Did you ever work on a JQuery codebase? (JQuery was an almost 1:1 mapping to browser APIs, do it's more or less equivalent to vanillaJS). Codebases based on modern frameworks, especially React, are much less complex than codebases based on the old approach. Back then you'd get lost in the weeds of DOM manipulation, and it'd be hard to see the big picture at all.

In my experience most of the incidental complexity in modern apps comes from inexperienced devs doing things that simply didn't need to be done in the first place. Very little of it comes from the frameworks.

[AgentME]

This completely matches my experience. I've worked on a 200k+ line javascript codebase that originally used just vanilla HTML DOM management and jQuery for everything, and I've helped introduce React into it over the years.

Every time the old code needed to place a view inside of another view, it was a fresh adventure in the exact way that sort of extremely common routine operation shouldn't be. Understanding a module always meant understanding its approach to managing its DOM elements before you even got to its business logic. Modules often chose between having simple-but-janky code that re-created DOM elements from scratch every time anything in the view changed, or having more-efficient-but-complex-and-buggy code that intelligently updated only the changed elements but often had inconsistencies with the first-render code causing some values to not work if they got set while the view was already mounted. People tried to establish some conventions across a few modules, but the chosen conventions often had significant drawbacks or only worked in specific cases because the people making the conventions didn't have the experience of library/framework authors.

I remember working with a coworker sketching out an idea of a convention we could develop and use for updating text and substituting in translations and live values. One of my main goals was to allow our modules to have the same code for the first-render and subsequent renders without having to replace all the module's elements with new ones. It was originally intended for just updating text, but I started to realize it would have to handle arbitrary HTML and embedding views from other modules to really be useful. The idea felt like it would need special cases to handle that, and I couldn't get the idea further. Then I later found React, and I realized it was a generalized approach to accomplish exactly what we were trying to design. I got the green light to use it in a few new modules, and even coworkers who weren't yet familiar with React could see how the modules were much more focused on the actual business logic rather than being absolutely filled with so much unique DOM-manipulation code. Everyone was sold on it within a few months, and people that needed to make changes to old modules would often choose to move the code over to React first to make it simpler to work on.

[yitianjian]

I also feel modern web apps are just much more complex than those from the jQuery era. So codebases have to do a lot more. It's hard to find a 1:1 mapping, as we just didn't expect as much out of the web in those days.

[TedDoesntTalk]

Complete BS. Not true at all. the jquery era had ajax with dynamic dom updates, dynamic svg, css, and many things we have today except for websockets, web usb, mic, camera, and other devices. the difficulty was more around each browser implementing things differently. and css was a nightmare. just to center something horizontally or vertically (or both) took patience.

[girvo]

It’s not “Complete BS.” — just because we had those features does not mean most businesses used them to the same extent we do today. I was deep in the front-end weeds in 2007 and onwards, and while I may have been doing some neat stuff then, the complexity pales in comparison to the sheer amount of business logic that now lives client-side.

[TedDoesntTalk]

That's because you have 13 more years of experience now. Or you like to revise history.

[austincheney]

jQuery is constantly tested with all of its supported browsers via unit tests. However, a web page using jQuery may not work in the same set of browsers if its own code takes advantage of (or falls prey to) browser-specific behaviors.

https://jquery.com/browser-support/

That quote says that if you attempt to solve for a cross browser conflict using a standards based approach it will likely conflict with jQuery code in the page. Either your approach will fail due to changes imposed by jQuery or your approach will break something supplied by jQuery. That is bad mojo.

Another problem I have with jQuery is that it encourages extremely inefficient practices in exchange for convenience. For example consider jQuery's closest method, which looks great if you don't consider the steps that execute under the hood to make that happen. In contrast using a non-jQuery approach generally meant event handlers that more directly target specific nodes in the page without all the necessary DOM walking.

I also remember jQuery frequently breaking IE back in the day. IE uses instruction count to determine if there is too much code in the page, whereas other browsers use a 20 second clock to warn on long executing code. Since jQuery does a bunch of unnecessary things and encourages method chaining those instructions counts would quickly add up and IE would stop executing code.

I have also found for many developers that jQuery is/was more of a live or die crutch they cannot live without opposed to a time saving convenience which was very off putting because developers were unreliable when things broke or when things needed to execute faster.

[greggman3]

It's 10x the code now. 10x = 10x more space for bugs and bad design.

Use to be I might setup a handler on an input element to update a value. Now I have to write an action factory to generate an action to get reduced into a function that updates the value. From simple data.prop = elem.value to 4+ functions and a bunch deep deep overhead.

Now I'm not saying all that structure doesn't have benefits but it's also a large amount of rope in which to hang yourself.

[nicoburns]

I honestly think it's about a quarter of the code. Yes, there's a bit of ceremony around state management (but you are also free not to use Redux). But it's mostly boilerplate with a prescribed structure, so IMO it's pretty difficult to get it wrong.

On the other hand, most of the code has always been DOM manipulation, and having that declarative rather than imperative is a huge win. The alternative used to be using a template engine like handlebars, but that did a complete re-render every time any state changed, so for anything moderately complex that was too slow and you had to fallback to manual DOM manipulation, and manually keeping the DOM in sync with your state. And that was a large amount of rope in which to hang yourself

[mosdl]

Yet we all managed to write complex web applications without much trouble that performed better than React ever can. DOM manipulation was needed rarely actually - usually you replace subtrees anyways (switch tabs, etc).

[Drew_]

If DOM manipulation is rarely needed then your web app isn't complex, it's at most a collection of CRUD pages. UI Frameworks like React are for building UI's that accomplish a lot more than that through frequent DOM manipulation. If all you need is CRUD then templating frameworks still exist, are well maintained, and widely in use.

[mosdl]

Even in complex apps, most of the DOM remains the same and you are changing several properties (some text, changing some classes).

[spiralx]

That's not true as soon as your UI contains conditional logic or a list of elements, at least one of which will be present in almost every web application.

[orange8]

> ... and having that declarative rather than imperative is a huge win. The alternative used to be using a template engine like handlebars

While React markets itself as a declarative DOM manipulation library, any kind of HTML templating system is declarative out of necessity. Why? Because they all produce HTML in the end, which is itself a declarative markup language.

[girvo]

I make my money by wrangling old jQuery and Knockout projects into 2020: I can wholeheartedly agree with you