Thanks, I use JSDoc for several years, and also validate it with Typescript.
So I just write plain Javascript with JSDoc, with no build step.
Typescript only validates the types, and not transforming the code.
Did you also know that you can import Typescript types/interfaces in JSDoc?
So for me typescript is not a language anymore, I use only the tool to validate the types.
Best thing for me was not removing the code transformation (convert ts to js), but separate runtime code with documentation code, like the types.
Gives you much more clear insight that the types you write to describe what you expect the type will be is not forced on runtime, but is just for you as developer to know it.
And when you validate the input is the right type, it is much more clear that it is the runtime type validation.
You can still use JSDoc in your typescript files, but why do you want to do that? There is no reason to do that.
So using JSDoc or Type Annotation, both works the same, same benefits, it is only personal preferences. Both have its pros and cons.
For me the JSDoc has more benefits.
Some other people prefer annotations.
But there is not 1 that is better in controlling the types, has more options.
(Also the enum can be done if you are using JSDoc, but is a little different)
Microsoft just fork Atom, and Atom had already good and a lot of extensions.
Before Microsoft buy Github, there was no reason to switch to VSCode instead of Atom.
When Microsoft buy Github, it received Atom from the Github team, and Microsoft stops the development of Atom.
VSCode was just Atom with the Microsoft brand, and some little tweaks from Microsoft, never a game changer compared to Atom, like Atom was in it's time.
Now Antigravity is again a fork with some little tweaks from VSCode, no game changer, just with the Google branding.
Next.js is indeed not very open for feedback.
Next.js is also opinionated.
So if you are using Next.js, you can use what they have and do it their way.
If there is something, just wait...
For me, it isn't a framework I want to use in any production environment.
Your system is too much depending on something you have no influence on.
Like in your own code, it is good to decouple, don't make things depend too much on something, not in your own code, but also on external code like frameworks and libraries.
That is why I prefer to build things like I can (kind of) easy drop my dependencies, for what reason, and use something else, or build it in my own codebase.
If some framework doesn't allow it, and you have to work it their way, and is the base of everything, that should be a big red flag.
To be a better programmer, write little proofs in your code.
We call that tests and types, proof that it should do what you expect.
Especially when writing tests first, then types, then the code.
Start with a test per acceptance criteria, that well describes what it should do, and is clear what you send and receive.
Also in an API you can describe the API in OpenAPI or GraphQL with all the properties and types, and you can validate on runtime the data on your specification, that specification is than also a proof that the application does what you described in your specification.
So OpenAPI/GraphQL, tests and types and proof that the system works like intended. Always start with that before writing code.
The specification is a solid base that doesn't change a lot if you start with it.
How the code works, you can refactor it, and proof with the specification if it sill does the same like before.
I remember that I did the same in 2005-2006, just combine XML with XSL(T) to let the browser transform the XML into HTML.
After that, also combined XML with XSL(T) with PHP.
At that time modern way of working, separate concerns in the frontend.
Around 2008-2009 I stopped with this method, and start using e.g. smarty.
I still like the idea of using all native methods from browsers, that are described at the W3c.
No frameworks or libraries needed, keep it simple and robust.
I think there are just a few that know XSL(T) these days, or need some refresh (like me).
Emission zone shouldnt be the issue, it is about the amount of cars and road safety for every user.
Check e.g. the Dutch road design, where many kids ride bikes.
This is already for decades, and has nothing to do with emission zones.
But another road design can also help reducing emissions.
It is about how many people can travel safe, and with big cities, you have to reduce cars to increase the amount of people that can travel safe, like bikes, walking, and public transport.
Road and city design is very important for a livable city.
When you build an API, please start with the OpenAPI specification, before you write any code for your API.
It can be iterative, but for every part, just start with the OpenAPI, and think about what you want from the API, what do you want to send, and what to receive.
It is like the TDD approach, design before build.
Writing or generating tests after you build the code, is the same as this.
It is guessing what it should do.
The OpenAPI specification, and the tests should tell you what it should do, not the code.
If you have the specification, everyone (and also AI) can write the code for you to make it work.
But the specification is about what you think it should do.
That are the questions and requirements that you have about the system.
I like the idea, think about what you really need, keep it simple.
I also try to move centralized computing to decentralized computing more and more.
And that can also be done to let the client do more computing.
And also storage, is it needed to store in central, or can the user store it.
Many times people thinking that we should have a central system, with all the truth.
But let it be a part of the users.
It makes also the central part simple, and because the central part is simple, it is easier to scale.
So true, we build large complex frameworks, abstractions over abstractions.
Try to make things easy to build and maintain.
But I think the problem is that many developers that using these frameworks not even know the Javascript basics.
Of course there are smart people at these large companies.
But they try to make things easy instead of learn people the basics.
We over engineer the web applications, create too much layers to hide the actual language.
20 years ago, every web developer can learn building websites by just check the source code.
Now you can see the minified Javascript after a build, and nobody understand how it works, even the developers that build the web application don't recognize the code after the build.
I love Javascript, but only pure Javascript, and yes, with all his quirks.
Frameworks don't protect you from the quirks, you have to know it so you don't make quirks, and with all the abstraction layers, you not even know what you are really building.
Keep it simple, learn Javascript itself instead of frameworks, and you downsize the Javascript codebase a lot.
Too mad that we have to hack our car to customize it.
We can reinstall computers very easy, choose the OS you like. But cannot do something on our car.
Old cars, you can modify everything, grap your tools, and you can do what you want.
Modern cars are too closed, you are too depend on the factory what they allow you can do.
Also are modern cars too complex with too many gadgets.
Please keep it simple, it is a car, not an entertainment device.
I love to build extensions.
Such a nice thing they made website source easy to read and manipulate for your own usage, and can even share your modifications to build an extension.
It is just like your newspaper, you can write on it, cut precies out, etc. You can do with the site what you want for yourself.
The newspaper designed also it how they like, but you can also grap your scissors and pen to change it for yourself.
There is a standard for browser extensions. I build also browser extensions before the standard.
So you can build now a browser extension that works in Chrome, Firefox, Edge and Safari.
But indeed, you can also use some specific api's for only a single browser.
That is really bad, like you build a site only for a single browser.
But the base should be compatible.
And because you always can see the extension source code, you can modify a version for your own that works well in your browser. (And you can share it again off course)
ESM is a defined default you find back in ECMA specifications.
That is why everybody should migratie.
Node.je is also moving ESM to the default.
If some systems dont do it, dont use it anymore.
That it went i dont use jest anymore, and Node.js has also now a good test runner.
(Useful for packages and backend systems, i think for frontend systems with eg React there are better test suits to help with special frontend stuff like the DOM)
That it why i use native functions.
No typescript syntax, no jest.
For testing i use just the native test runner, and that works great with ESM.
Jest has indeed still not good ESM support, you can do some Babel trics, but makes the process too complex.
Best is to find an alternative, like the native test runner.
Also typescript try some things that are not stable at ecma.
It was too soon with the import/export, and dont use the native way.
Also commonjs is still the default at typescript after compiling, but Node is moving to ESM as a default.
I hope typescript will use more native functions that are already available and dont use their own way.
For me typescript syntax and jest is a no go.
Typescript is useful to check types, but i write just JavaScript with JSDoc, and check it with eslint in typescript modus.
Why not using Node how it is designed, than ESM works great.
For type checking on development, you can do it with ESLint and JSDoc in Typescript modus.
You have the same type checking like you have in ts files.
You can even import types from typescript files, like .d.ts
Best of both worlds, no transformation of the code, and on development you have some help from Typescript.
It is type safety at runtime.
Typescript gives you some type safety at develop time (like jsdoc also can do)
But if I read it right, this helps you to generate OpenAPI spec to validate the api endpoints, to get easy type safety at runtime.
See also e.g. https://openapistack.co/docs/openapi-backend/intro/ that is also helping to be type safe at runtime.
Or Nest can also generate OpenAPI als validation based on it.
Only difference is that OpenAPI stack is design first, and Instant is code first.
And Nest use decorators and Instant JSDoc.
It is more like https://www.npmjs.com/package/swagger-jsdoc that generate the OpenAPI from JSDoc.
To use Typescript or not doesnt matter, it is about runtime validation.
The one like the native JS way with JSDoc, the other likes Typescript and doesnt matter the build step for the API.
Typescript wil not help, you can create the same mass.
What me helped is to write almost all code functional and not oop.
Every method had just 1 way data can in and out the method, no side effects.
Classes have a lot of flexibility that make things complex and increase bugs.
If you are strict in what to accept and what to produce, and start with the test, if you create mess, you can eat refactor to create clean code.
Funny thing is that a lot of developers like that JavaScript received class support, and makes it easier to write oop.
Many people dient understand 'this' in JavaScript, and ways are created to reduce the usage of 'this'.
And now people are switching from classes, a feature many want before and complained it was not in JavaScript.
I think we always have to accept the language how it is, and dont find weird ways to do things the language is not made for. (like e.g. typescript)
Why need another dialect if you can just use Javascript.
I think most people don't really know Javascript, and what is possible.
Most arguments to use Typescript are not good arguments, and Javascript can more than most people think.
Typescript is more a combined box of tools, and a lot of things can be done without Typescript or another dialects.
I think, if you write server code / command line apps.
It is better to choose for Javascript over Typescript, so you don't have the translation, and you know the system where you running on, and you can build for that Node version.
Typescript makes it indeed too complex, keep it simple with just Node.js without a build step, or use indeed another language like Go or Rust.
I always say, Typescript is no language but a dialect.
JavaScript is the official language that will used in production.
You can talk in a dialect, but for official things you have to write and talk the official language.
Always think if the Typescript dialect will help your team, or it can cause confusion, e.g. after translation to the code that runs in production.
(Error reporting, debugging, running tests, ...)
Javascript is easy to write and understand, easy to play with, without transpiling, e.g. in your browser.
When you write code in the native language, you know what you write, how it will run on the system.
When you write in Typescript, it generates some Javascript that is sometimes hard to recognize as your code.
No, you don't need a build system, but most developers cannot work anymore without a build system.
And what about node.js, it's a lot better to skip a build step.
I think typescript is a temp hype just like jQuery, useful for many, but a few people can just do the vanilla JavaScript way.
It shouldnt, the concept of an EV is simple, but car companies add to much gadgets.
Just look to electric remote toy cars how simple the basics are for an EV.
Lets make EV cars just as simple as electric toy cars.
Keep it simple, dont make driving gadgets.
Indeed, i had also a Golf (TDI) from 2005, very reliable car that works always, it is simple and everybody can repair it.
Why cannot they make EV's that are simple, we dont need all the gadgets that will break.
This is indeed not limited to EV's and cars.
Search e.g. on "John Deere right to repair", and you will see that farmers cannot repair their own tractor anymore, and need the factory dealer to repair it, and the owner have to wait and cannot do anything.
Prices of old school tractors are rising, because a lot of farmers like to repair a lot of things, so they can keep going, and dont have to wait for a mechanic that can repair it.
On your car, i also like old cars, because you can bring it to every mechanic, or do it yourself.
I like the basic car, and hope EV's will come that are also simple and build like Lego, so you can easy switch some (electronic) parts.
Who need large displays, self driven cars, and other gadgets.
A vehicle is just a useful thing to bring you from A to B on a save way, we dont need distraction from all the expensive gadgets, just safety and comfort.