"ExtJS was a mistake. One we, as a society, may never recover from."

When I worked at Pearson's startup Alleyoop around 2010 or so, we had an incredibly bright intern named Slater, currently CTO of his own machine learning startup.

On FB he posted

ExtJS was a mistake. One we, as a society, may never recover from.

Our dialog proceeded as follows

Kirk:

Oh my goodness. I thought you would be hipper and getting into the game after ExtJS was recognized as a mistake!
It's funny, I talked with this one engineer I respect but never should have been making UI architectural decision - In 2008 he put us on "Wicket"... all this client-y looking code is in Java, and you have to carefully keep synchronized these divs in the template and their corresponding nested Java objects... blargh)
In 2015 I was talking to him about his shoehorning us into Wicket, and what he, as a primarily serverside guy, would like in a UI. It turns out mostly he wanted to not have to learn HTML5 and especially CSS. "I want to be able to just ask for a button - programatically - and it gives me a button."
I realized ExtJS was probably an extension of this kind of thinking.
It was hard to learn and understand (rather opaque!) and also hard to debug in the browser - all these little widgets with absolute positioning and then given exact pixel coordinates... I'm sure they were doing some cool stuff early in a cross-browser way but man.
The hoops some engineers go through - the extravagant toolkist they then have to learn - to avoid learning some very basic stuff...

Slater:

In a bizarre twist of fate, I recently picked up react + redux (not that I know what I'm doing on the frontend), and then saw an ExtJS stack. Suffice it to say I was horrified, but I think you're spot on about the logic.
I get not wanting to learn a new toolset (one could argue that a lot of cases where node gets extended beyond its sweet spots is another flavor of this same thinking), but anyone should be able to recognize when a framework is pushing them toward unmaintainable code.

Kirk:

A lot comes down to if developers prefer to understand things bottom up / via reductionism (in which case they value very transparent tools - even if they have to write a lot of the grunt work code themselves - the code base might get gnarly and complex but at least it's complexity specific to the application at hand) or top down / holism (in which case they might prefer a richer toolset that makes it easier to write in broad strokes - if the toolset is harmonious with the problem that's great, but chances are the toolset solves MANY people's problems, not just yours, so if you have to track down a mysterious 'whyd this go wrong?' it can be brutal)
Besides the holism/reductionism split, there's also nouns vs verbs; devs like me prefer verbs - I want to describe what I want done, in a more or less procedural way-- whereas noun thinkers want to make something that knows how to do the stuff. So here I like react, where the nouns (the JSX bits embedded in code) live sprinkled among the verbs of code, and you can put in a very relevant breakpoint, or inspect the state. Vs ExtJS, where you specify the nouns and it tries to write the verbs to get you there, and god help if you need to track down how the nouns got to the state they did.
When it comes to toolkits, my heart lies with vanilla-js or DOM manipulators like jQuery - I cut my teeth on caveman CGI, where the DOM was a very static thing that came back in one fell swoop from the server. When I added jQuery into the mix, the verbs I could do in the client multiplied, but the DOM was still that static noun thing, changing only at certain points which were more or less easy to track. Over the years I've felt validated that this is a pretty strong paradigm, as I've seen toolkits come and go, but React has come closest to feeling what might be the actual future, and I don't want to jeopardize my career by sounding like a cranky old stuck in the past dude.

Slater:

Kirk, also I agree with this a lot. Personally I don't feel the noun/verb distinction super clearly, but that's probably because I switch between functional and OO paradigms a lot. I think especially for people coming from a noun-centric (read: Java) environment, learning the thought process behind a generally more verb-centric (read: javascript) environment can be very tough.
Additionally, I'm super, super reductionist. I like tools, and I love standing on the shoulders of giants, but I tread very cautiously when it comes to adopting a new framework, and it's very important to me to understand exactly where the limits of the tool are. I really enjoy APIs for this reason, and I think there are a lot of heavy frameworks that go the wrong way on this (for me at least) by enforcing large amounts of state, and making it unclear how you would extend the code.
I think jQuery is a really simple and straightforward way to built a project. I think that it's quick to pick up, fast to prototype with and for small projects there's nothing wrong with it. My gap comes from the perspective of maintainability. There are a lot of code smell niceties in something like python, generally focusing around clean code abstractions, decoupling data from logic, etc... that can be really hard to get right in plain jQuery. Even something like splitting code up into multiple files and using functions across them can get surprisingly gross pretty quickly just because of how the namespaces are set up.
I think that's the biggest advantage of React (I'll say Angular is pretty damn close to React, and from a macro-level they're almost interchangeable. Angular just feels like a bigger, clunkier version of React to me). Very clear separation of concerns. Clear lines of responsibility, and built for re-usability.

Kirk:

Enjoying this dialog Slater.
The way you used Java/Javascript as your example for noun v verb pinged something in me: I know the shared "Java" in the name is coincidental-ish but there's the "script" part - and that being verb-centric - "I want the computer to do this". It made me think of a defense of PHP I reread recently - Taking PHP Seriously - besides talking about how the odd dichotomy where the language is much reviled yet so many big league projects got at least their start in it - and in looking for some answers, mentioning that the script-ish way it gives you a "from-scratch" clean envioronment for each web invocation - that's actually tremendously powerful.
I can't always separate my long-standing biases (and roots doing personal projects where I was the only developer, though some of those codebases have lasted me decades, literally) from my "graybeard" experience, but I feel like I haven't seen much many systems that were clearly easier to understand and bring more people on later via leveraging higher level things. Whatever advantages were gained in using boilerplate were more than eaten away by a combination of new developers having less experience with the platform and generally being MUCH harder to debug from a bottom-up way. (i.e. completely opaque stack traces etc)
For namespaces... I dunno. Just throw everything into window.MyProjectName = {} and be done with it ;-D
The fact Angular and React feel so similar to you indicates that we view things very differently (admittedly I've done more hacking in Angular and only toy things in React so far). Elio who is posting here loves Angular, I hate it - who thought "client-JSP" would be a good idea? That is to say, "we love writing tags so much, we're going to let you make your whole View in nothing but tags - never mind how much syntax you have to learn in both the tagspace AND the plumbing that lets it all look like html tags. But more to the heart of our conversation, for me tags are nouns, the fairly static nouns of the DOM, so trying to make them all verb-y with loops and conditionals, and so it's blend of "this is a tag for the browser to render, this is a tag for the view's logic" feels strange to me. By putting the noun tags in the verb logic, React does something a little similar at a high level, but at least the logic and the display are in distinct languages (js vs jsx)
Heh, reminds me of How it feels to learn JavaScript in 2016 . Probably a warning sign that I still think more like a prototype cowboy is how much I looove just writing an index.html, a style.css, and app.js (and then I sort of love that "ok so put it all in one document anyway" paradigm ;-)

Anyway, very smart guy, one to watch out for.