This is the way.
This is the way.
Except when a bug pops up somewhere. Ownership/Responsibility changes in sub-Planck-second time when assigning blame.
Sveltekit is the fullstack/SSR version of svelte (like next is for react or nuxt is for vue). I reckon learning one of them might be helpful to learn component-based SSR and its benefits, personally I do think they have a firm place in the future of webapps.
Vite I can highly recommend, it’s the best, fastest and least fussy bundler/builder I have ever used hands down (having used webpack briefly and packer for a while). Has some great features and is less of a pain to configure and get to work in my experience.
I would argue that the same things were probably true in western capitalist countries at the time (I have no evidence)
The CLI is scriptable/automatable and unambiguous when sharing instructions with coworkers. Both of these things make it very useful to know the commands. I do agree that it helps in some situations to visualize what is going on with a GUI/TUI though (neogit for nvim or magit for emacs are great if anyone is wondering), it can make things clearer at a glance.
But… But :x is superior because it doesn’t overwrite unchanged files with a new modified date :(
Test driven development. It’s a technique where you know what behaviour or result the code should produce, but you haven’t written any producing code yet. So you break down the problem into small steps which each produce a testable result or behaviour that brings you closer to what you need. And before writing any implementation for each of these small steps, you write a unit test which checks whether an implementation would execute this step correctly. Once you have each test set up, you can start writing the implementation, keeping it as simple as possible, and running the test until it passes for your implementation. This keeps going in a cycle.
Once all your tests pass, provided you’ve written good and correct tests for every step, there are several benefits of this approach:
The downside is that it takes more time to write tests for everything. But for complex applications, it will save you a lot of time in the long run if the code will be changed very often in the future or is complicated, because many bugs will be caught by your test landscape.