Some feedback

[eldoy]

If we had never started using ESM, JSX, React, Typescript, SPAs, Babel, transpilers and front end frameworks in general, and instead just wrote HTML with template tags, CSS as CSS, used micro frontends and vanilla (functional) Javascript, then there would never have been any of the problems that you suggest we need to solve. The only thing we need to make faster web apps is maybe bundlers, which should simply just join and minify assets for production and is trivial to implement.

In reality, all we need to do is to stop, and revert back to doing what we did 10 years ago. You can start doing that today, and everything will be just beautiful. All problems solved.

I'm writing applications like this at the moment, and they are super fast, no transpilation, no frontend dependencies, very developer friendly and just a joy to work with. Which problem is everyone trying to solve? Everything is just getting more complicated, it's insane. They've invested so much time in this "problem" that it's too late to admit it's a failure, so they just have to keep going, and hope that they won't look stupid in the end.

As a separate discussion, I wouldn't even mind reverting some stuff in Javascript itself, like await and classes, to make things even simpler. The only thing from es6 that I like is the spread and destructuring stuff, which also wasn't really needed, just a nice to have. If Javascript could be "locked", similiar to what golang is doing, then everything would be more stable, predictable and faster, and we wouldn't have to worry about things not working. How much is Javascript engines being slowed down by all these new features being added all the time?

[giltayar]

@eldoy I don't want to revert the advances we made in software development in the past 20 years. I like them (well, most of them). I like ES20xx, I like async/await, I like ESM, I like TypeScript, and I like most of the frameworks. I do not want to go back to writing in VanillaJS. Things became (as you say) "complicated" for a reason: the software that we write has become more complicated. The point of my talk is not "to revert JS and web programming to what it was 20 years ago".

I'm not saying that you don't have a point. Yes, I think most websites do not have to be SPAs. MPAs written with simple JS are fine, and will remove a lot of complexity around developing them, but that is the subject for a different talk (maybe you can write it!). But for those sites/apps that need the complexity, modern JS code is useful.

If you look at my outline (https://docs.google.com/document/d/1xcUG7p-4YMgqLeAh9sqbtCpwKsnh31dM6DNZxsGOOJM/edit?usp=sharing), you will see that what I'm trying to say is that the toolset required to support modern JS code is not necessary anymore, and is now a liability more than it is a help. We can simplify the toolset and the ecosystem.

Thank you for helping me with this distinction. I think it's an important one, and should be in the talk.

[eldoy]

@giltayar Ok, fair enough, but my point is that it's actually way easier to write SPAs using Vanilla JS, even the most complicated ones. I'll show you how if you don't believe me. The community, and the world, will be better off if they know how to do that instead of using all these complicated frameworks and languages which only leads to fragmentation and a waste of time and money. It's truly mind boggling that people like spending time writing type definitions when it's not at all necessary. Don't they have anything better to do with their time?

IMHO all of these so-called "advances" were just a complete waste of time, and the amount of time and energy spent making something we never needed in the first place is borderline insanity. Is it worth sacrificing stability and speed for a bunch of nice-to-haves?

But I guess people have different opinions on what to use software for. Most of the commercial space around software development have strong incentives to make everything as costly and poorly as possible so they can keep charging for projects that never really finish, and which will expire the moment you release them. For them, slow, confusing and bad is actually good.

Anyhow, looking forward to your article! I really enjoyed the work you did in regards to communicating the usefulness of JSDoc. Why do you think writing Typescript is better than simply using it as a linter for JSDoc? That I don't get. Wouldn't it be better to use resources on standardizing JSDoc instead?

[giltayar]

JSDoc is wonderful! At Roundforest, the backend people loved it and the verbosity wasn't that problematic, because in the backend, the use of types is mostly around describing the data structure, and so simple.

Frontend? They hated it. Frontend today is TS heavy and uses all that TS stuff that causes headache. I forced them to use it for a month to see, and after a week they came crying back and saying that they want their TS stuff back. And since they're transpiling anyway, then we settled on doing it the TS way.

So, yes, JSDoc is wonderful, but its verbosity can sometimes be problematic. And as I said in my talk about type annotations: it's not about what I think. It's all about what the community thinks. And the community chose TYPESCRIPT. In capital letters! With a big majority vote.

So in the backend, I'll definitely continue using JSDoc. Frontend? TypeScript, and wait for type annotations to get standardized.