[j-pb]

I'm glad that you had such a positive experience! After years of web development I'm just burnt out by the tooling.

Layers upon layers, just make debugging so unnecessarily hard. The tooling is brittle and buggy.

I've seen typescript compiler bugs, webpack segfaults, and whatnot. I've started to ban typescript and jsx from all future projects, and it's better, but still a nightmare.

[jspash]

I’m on the fence but painfully with both feet on the ground. However it wouldn’t take stiff wind to knock me back on to the plain ol JS side.

I’m currently “rewriting” a vue.js app for the sole reason that we’ve just lost a senior dev who was the only one who could stomach the thing. We’ve taken on two juniors in his place and there is absolutely no way they would be able to dig into this thing.

The process has been quite enjoyable and we’re just about at feature parity at 1/10 LOC. And the juniors are quite keen at picking up typescript and lots of other useful things along the way.

Had they just been dumped into the vue pool, things would have turned out much differently.

I await the day a few months from now when they “discover” this new thing called vue and want to rewrite the entire thing!

[murukesh_s]

>“rewriting” a vue.js app rewriting to what?

[Xevi]

As a mainly frontend developer, I agree. I've spent more time configuring tooling, than writing code, in this new project I'm starting. I don't want to write plain JS, but the top used frameworks have strayed so far from basic JS that it's getting a bit ridiculous.

Svelte appears to get rid of some of the boilerplate and verbosity stuff you find in other frameworks, though it's still a pretty magic framework. Looking forward to trying out SvelteKit.

[selfmodruntime]

I've seen this take a lot lately, and frankly most of them are straight out lies. Your post may be one of them.

The top three modern frameworks all use cli-tools that do the config for you. Most are astonishingly simple to use. There are the rare times you have to venture into using custom webpack configurations, but they are far and far between.

You say the top used frameworks have strayed far from basic JS, but that is not true. Most of them are 90% vanilla JS with the exception of Angular. Hell, even React Components are simple JSX transforms. A component transforms into React.createElement(<name>, <props>, <markup>)

[Xevi]

Idk what projects you are working on that don't require any configuration.

I just started a new Vue 3 project with typescript, Vite, VuePrime and some other dependencies, and there were a lot of undocumented steps and annoying issues to get everything working. JS-shims, beta version browser extensions, colliding ESLint rules, buggy dependencies that get compiled into broken JavaScript, etc.

[selfmodruntime]

Well, I‘d wager it‘s a likely experience if you venture into experimental frameworks. Vue3 is pretty new, as are dependencies that work with it.

I have not had any of these problems with `create-react-app` yet

[mikesabbagh]

The thing is, complexity cant be destroyed. You can just move it from one framework to another

[vlovich123]

How do you mean? If there’s a repeated pattern that is hand written al over the place without people realizing it (or not making sense within the local context to build something more general), centralizing that pattern certainly destroys complexity, does it not? The pattern existed before and after but the centralization means you have only 1 instance of this pattern.

[ehnto]

That wasn't complexity, it was repetition or verbosity. It's tedious to manage rather than complex.

In making it DRY you have introduced a dependency for all of the usages of that snippet of code, and made it harder to have individual uses deviate if they need to.

Of course that might be exactly what you want! It's just good to be aware that code reuse is adding complexity by way of adding a new system to manage.

A little function, no big deal. But if you find yourself writing models and extending classes just to save yourself a couple of repetitions you may have jumped off the deep end!

[mtone]

You now have to integrate that pattern/module, and learn/work with the tooling to integrate the pattern/module, which adds new complexity and constraints on top of the now-centralized hidden complexity.

On the whole, it’s worth it - building on the shoulders of giants lets us achieve great things with what used to require out-of-reach amount of resources.

But as a result our work has shifted towards more integration and tooling (everything from node/npm to cloud services, orchestration, containers, and ML/AI) and total complexity keeps marching on upwards.

[PurpleFoxy]

And that works well. After years of using react, I only have positive thoughts on it compared to the jquery apps I used to build.

Things that used to be so verbose and brittle before become trivial and reliable solutions in react.

[oraphalous]

Interesting that you're reacting against the Typescript trend...

I'm personally starting to wonder if/when the backlash against Typescript will gain steam.

[sombremesa]

The problem is that Typescript seems amazing when you're first starting out, and is especially appealing to devs coming from strongly typed languages - but, it's a productivity drag almost immediately (for seasoned JS devs), and as the software gets more complex you either get more and more type spaghetti or devs who spend days figuring out just how they're going to make that one type elegant.

All this to maybe catch one or two bugs, since the boogeyman of accidental type abuse rarely makes an appearance.

Some of the sacrifices made to turn it into a superset of vanilla JS come back to bite it as well. I think banning it from projects is a very wise move, but it's the kind of wisdom that's counter-intuitive and requires more of a business sense of things.

[yladiz]

> All this to maybe catch one or two bugs

I think you’re significantly underestimating the bugs that could be trivially caught with types. For example, Airbnb stated a while ago that 38% of their bugs could have been prevented with TypeScript[1]. Types aren’t the solution to all bugs - this is why we have strong test cases as well - but they bring a lot of benefit, especially if done with diligence, not just to prevent bugs but about to aid in understanding the system as a whole (seeing the types of an object can make it much easier to understand what data is being passed around).

1: https://news.ycombinator.com/item?id=19131272

[sombremesa]

Postmortems like this are highly suspicious. There are many, many questions such as whether these bugs could've been caught simply via linting, and whether whoever did this research engaged in p-hacking.

I could not find a single paper - the only reference is a slide in a presentation that may well have been pulled out of someone's ass.

Anyway, I do concede that typing has its value, but in a large project, the cons ironically outweigh the pros (for TS specifically). I'm sure other JS typing systems are actually better at that, especially the ones that aren't trying to be JS supersets.

[selfmodruntime]

Given that AirBnB supplies one of THE strictest ESLint / TSLint configs, I'd wager they were using linting alright.

[presentation]

I don’t know about your experience but TypeScript has saved my team an enormous amount of time and resulted in the near complete elimination of showstopping bugs on deploy at my company. We’ve had maybe one fire in two years of rapid growth and a large part of that is thanks to TypeScript.