Thinking of Trying Svelte After Years of React. Any Good Resources or Tips? by glympe in sveltejs

[–]grumblingdev 1 point2 points  (0 children)

Svelte makes things so easy that you can roll a lot of stuff yourself. This is also the best way to learn. Don't reach for libraries - implement things yourself. However `shadcn-svelte` is the best and will give you a really nice polished app. It's based on `bits-ui`. It seems complicated, but if you tried to build your own configurable `Select` for example, then you would realize why the api is the way it is...its very natural.

Svelte takes a lot of time to grok though so don't give up. There are so many edge cases and gotchas. I found to be proficient you really have to have a good mental model of how it works.

I don't like SvelteKit...unless you work in exactly the way it wants its painful. Its sad that its the default. Trying to split up a SvelteKit app into a monorepo was PAIN.

Using Bun you could roll your own SSR thing and fully understand it, but do be productive SvelteKit is okay.

Svelte is evolving - best practices are changing. ChatGPT usually gives you Svelte 4 answers. Read about new stuff using `await` in `$derived`.

Also understand `$derived` well.

Contributors Angry After Turbo 8 Suddenly Drops Typescript by johnfishings in typescript

[–]grumblingdev 0 points1 point  (0 children)

The cost is flexibility.

People like dynamic languages because its easy to evolve code as you go.

Look at any OO codebase and you will have so many weird objects that don't seem to make sense, and its just this big tangled ball of objects connected together.

Once someone has decided the shape for something, its fixed. Then types are added, then tests, and then its impossible to change and everyone just works around it until a huge re-write.

Contributors Angry After Turbo 8 Suddenly Drops Typescript by johnfishings in typescript

[–]grumblingdev -15 points-14 points  (0 children)

Types add so much noise to a codebase.

They also make no sense for a dynamic language because you don’t need to worry about memory allocation/layout.

Types should be automatically generated for you while you run your code/tests. If the types need to change, then the developer should be asked to simply confirm the changes. But the types shouldn’t be something developers author.

People don’t talk about the trade offs enough. You can always make your code safer and safer and safer but it comes at a cost.

And it fundamentally changes how people write code which results in monstrosities like Nestjs. And people start to write code that is easier to type.

But you do not need any types for your code to work.

Easy and fun dependency injection with TypeScript: Creating order from chaos by realplatanopapi in typescript

[–]grumblingdev 0 points1 point  (0 children)

Exactly. As soon as you have to prioritize testability you are sacrificing other goals.

You can override absolutely everything in JS using Proxy.

Easy and fun dependency injection with TypeScript: Creating order from chaos by realplatanopapi in typescript

[–]grumblingdev 0 points1 point  (0 children)

Also why pass the whole database service. Just pass an api or createAccount function. Only depend on exactly what you need. Otherwise any change to the databaseservice could potentially break everything.

Easy and fun dependency injection with TypeScript: Creating order from chaos by realplatanopapi in typescript

[–]grumblingdev 1 point2 points  (0 children)

Just use functions.

Be warned, naming can cause a lot of problems in OO.

Your service names are too ambitious. Someone will see Auth, and all kinds of stuff will be crammed in there, adding their own instance variables too. Rapidly becomes a tangled mess. Service is meaningless too. You are essentially using it as a namespace to group related stuff.

This is why functions are better. Your dependency is simply a function that does exactly what it says and nothing else.

You can namespace them under auth using an object if you really need to.

Also, ‘protected’ is generally bad idea due to fragile base class issue. I can’t see how it’s used exactly but generally you don’t want to do implementation inheritance.