I have since come to believe that this is a trap that many people fall into.

Even a colleague of mine at my current job might be sort of in this track himself at the moment I think. And I don’t feel that he is interested in listening to me at all. Even though we are supposedly on the same team.

I think these kinds of things, when you fall into the trap, is something that you have to eventually realise on your own why it was a bad idea.

Meanwhile I am at the verge of quitting because I find it frustrating that we are working on this thing where it seems I am not being listened to and we are implementing something in a way that I recognise from my own past mistakes as a patently poor way of going about things.

But at the same time, I love the company I work for, and the pay is really good, and I am scared that if I quit I won’t find another job for a long time that will pay well enough to support myself and my girlfriend and our expenses.

Anyway. Point is, I agree with you, there will always be people trying to build these frameworks and what have you.

There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously.

We don’t really have good measurements for - and often overlook those aspects - which causes us collectively to suffer only after a great commitment of time and labor. I’m pretty convinced that complexity isn’t just mentally confusing but actually hard measurable, as long as we have language to describe it and a well tuned skepticism towards unnecessary layers of indirection. Function coloring is one such attempt, imo, at explaining the great costs of something which looks innocent.

Is “can do X” included in that definition (ie are you alluding to composition vs inheritance)? Can you elaborate on what constitutes good abstraction, in your book?

- Browser incompatibilities. You couldn't just do X, because in other browsers X might behave differently. So you would write X blueprint and use an X factory that would auto-generate code for the different browsers. This applies to both JS, CSS and HTML BTW.

- Then the modules+bundlers came. Initially they were <script>, but when you had multiple you wanted to concatenate them for performance ofc, and in Node.js you wanted a way to import them. So a tool for each was created, then a tool on top of both was created, and thus a factory of factories of sorts was created.

- Then ES6+ came, which was similar to the first point so I won't bother you with it.

- Then Webpack and all of its derivates promised to solve all of the problems above, at the same time (with Babel and whatnot), and the era of mega-factories came to be.

Luckily nowadays we have standardize mostly around ES6+, and using ESM for imports/exports everywhere, so if you write plain JS and use ESM both in your code and in library code you don't need any more factories. You can still use a tool to bundle all your code, or to use more advanced coding paradigms like React*, but that's nowhere the peak of complexity we've lived.

That's one of the reasons I dislike TS BTW, because now that we are in "bliss plain JS" some people were not happy and had to add complex tooling again with TS.

*I draw the line here and declare that JSX is not JS, and thus this complexity thing doesn't apply there. If you are writing JSX you are writing it against CRA/Vite/Next, while plain JS you are writing it against the browser, so only things built on top of JSX, like TSX, can be considered factories from that point of view. If you think it's not fair, I'll argue it's as fair as JS, since in the end every browser is a "factory" of JS -> low-level code.

If you only know how to code within the constraints of the framework, you're gonna fail for anything non-trivial. If you try to ditch frameworks entirely, same deal.

Actually knowing how to code is important, but so is knowing how to take a problem and implement it without ever doing anything the framework authors didn't think of.

You might need a nasty hack like exporting a bitmap to a ramdisk and then importing it again to read a pixel value, to avoid messing with some nasty AI, or you might have a case where performance matters and you do want to mess with the buggy undocumented crap API.

It's almost like the idea that language shapes how you think. Frameworks are kind of like subsets or dialects of programming languages. If you actually know the framework well, you can often do stuff that seems like it would need low level control, in an idiomatic way that doesn't fight the framework.

I was thinking of building a Bluetooth device you can leave somewhere that alerts your phone should it be disturbed, as a portable security system. However the PineTime, an open source smartwatch, has all the features needed for $25, cheaper than almost any small quantity prototype.

Not sure if I'll ever get around to that project, but if I do, I probably won't be building any single function hardware just for it, especially not without being sure the whole idea is worth it.

I think the analogy does not quite fit. A framework is certainly not a dialect. For me a dialect is a variant of the language in which you can accomplish almost the same.

A framework provides you with a couple of blocks for building something specific.

In terms of language, I'd say a framework is like technical jargon. Additional abstract terms that describe concepts useful in that domain. So domain experts don’t need to always explain everything from the beginning.

You may re-use normal english words to have a new meaning. a bit like how companies like to have infinite initial acronym's for everything that nobody ever will understand outside the company.