w3news

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.

Code is less important than the specifications.

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)

Good old times, when the web was simple, and more decentralized

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.