Refactors or basically all cases of maintaining legacy code are the biggest reason to use typescript for me. So while you might be faster developing a new feature, if you ever have to touch it again, it'll take a lot longer without types.
10:44 - That adding and removing of a class onclick is a simple single line of vanilla JS. The checkboxes are also very easily styled. You don’t need ANY frameworks for that. None.
Btw if the editor was slow to display intelliSense it is due to Typescript LSP being notably bad. It is not an issue in TypeScript itself. You could have a Rust or Golang code base having the same issue.
Htmx can do what you showed, it is not that hard at all. It is just a backend endpoint returning the html with the css and another without and each of them having htmx tag pointing Ajax to the other. But I do agree with you. I prefer SvelteKit over raw dog Html. And I was pro TS but I also live JS + JSDoc just for the sake of simplicity, like you said: don't loose my time pleasing TS compiler because blabla isn't this or that. But TS also has a lot of rules to check your code which prevents some hic up. So serious, multi dev project is TS over JS+JSDoc.
@@RatchetXJ0461 for something as simple as toggling a class, you could also potentially use hyperscript to implement lightweight client side scripting. It pairs well with htmx and shares the same creator. Personally I wouldn't want to add in the overhead of an http request just for a small client state change
Classes are perfectly fine and I use them more often than factories. They only become mildly strange if you build class instances out of other class instances provided by some frameworks. Then it gets a slightly longer prototype chain, wooptie doo.
Another thing to note, I can be my own compiler. If something goes wrong and there's an error literally everything you have to do is: go to line => look around => write _debugger;_ in the most convenient spot, and run the file. In case there's no error you should console log a couple test cases to see if the outputs are good or not. If they're not then do what I just described earlier, you know where the function is located.
It’s easy to fall into writing JavaScript when you should be writing ”typescript”. People try to make everything dynamic when that’s not the advantage of typed languages. Try to keep to basic types and reach for generics sparingly. But typescript performance issue are real. Explicit returns and noninferred types can make performance much better
if you are working with 200 lines of code that you wrote your self, sure js would be fine. make it 5 yo project with 10 maintainers then ts will become a necessity
Dude `user` is _exactly_ where you want to be using typescript. that `UserObject | null` is massively important. You probably don't know the shape of `UserObject` being that it's pocketBase, and is something they may update overtime. Second, typescript is going to make you properly handle the `| null` case. Even as small scale, those are going to help you write non-volatile code. Typescript is a _tool_. Using it and writing code to it's advantage is going to make you a better coder. Ignoring it, either like this, or with abundant usages of `any` and `// @ts-ignore` is just going to lead to runtime errors
I think if you are working on a project alone or with a skilled team of programmers you can get rid of typescript. But in most scenarios you will be working with a team of junior devs that will write some inificient code and a chunk of that code will be pushed into production, and here is where typescript is important.
10:30 that's literally one css class saying .border-greed { border-color: gradient() } or something like that, and one HTML based onclick function. No frameworks. HTML and CSS. Hell you can even write the entire property change of border into that one function without any CSS files and the function is embedded right into the HTML.
Excelent video! You made really good points. Not sure if i agree with you in everything you said. But, for the most part, i think we share the same opinions. Btw, i really dig your font and vscode theme. Would you mind sharing them?
00:00 that's what I call enshitification of development. People don't know what their computer is doing, don't even know what their code is doing, they just complete a 30min bootcamp and copy paste that one thing they learned that works ok, without knowing what to do when it breaks. Johnathan Blow said a similar thing about more low level game programmers, now imagine javascript devs. I despise the idea of typescript because first you need to understand how javascript works and why it fvcks you up. I do, I have been writing vanilla js for 6 years. And now on top of that I have to understand what bs the typescript transpiler does and why it fvks me up *on top or in tandem with javascrip?* This is just fancy comments with extra edge cases, that end up in an already edgy javascript code.
Hi senior frontend developer here with about 20 years experience; here is my observation that no one talks about. I’ve seen time and time again entire communities around a syntax preference become obsolete virtually overnight by a raw language’s adoption of said communities syntax features. Case in point, the down fall of jQuery back in the day.. So I keep telling younger developers that aspire to be a full stack developers; the stack shifts out from under you constantly unless you admit one simple fact.. libraries come and go, raw JS however seems to live forever.
If you're worried about people on the internet calling you names for using Class syntax, you can substitute a plain object in many instances. If you're just using the Class to contain some data and methods then the following would also work fine in Svelte 5. export const farm = $state({ farmer : 'Jim', animals : [ { name: 'cow', alive: true }, { name: 'horse', alive: false }, { name: 'pig', alive: true }, { name: 'chicken', alive: true } ], kill : function(animal_name){ let x = this.animals.find(animal => animal.name === animal_name) x.alive= false }, getOwner : function(){ return this.farmer; } }) You don't need to use the 'function' syntax either, you can just write getOwner(){ return this.farmer; } But I prefer the longer syntax. Personal preference. The Class syntax in JS is built on top of object prototypes so if you're not using any of the Class features (like inheritance) sometimes a plain object is a cleaner choice.
I think the two biggest criticisms of TypeScript are being lumped together and it's funny because they couldn't be more different There's the folks that want to give up on types altogether, which I think is crazy. Then there's those who don't like TypeScript because it's just a linter, the types are not real and they fully disappear at runtime, which invalidates all possible type safety guarantees At that point you could just use JSDoc and get rid of the build step
The build step is literally not adding a single extra step in the context of building an application. You already have a "build step" when you build your Next/React/Vue/SvelteKit/whatever app. Why on earth would you use 400% more characters with JSDoc? You literally gain nothing from this. I'm somewhat more sympathetic in the context of building a library, but there's literally no point dropping TypeScript when building apps.
More and more frameworks (like react with the React compiler, svelte uses a compiler too) are relying on build steps, so why not just use TypeScript for the better typewriting experience (TypeScript just looks nicer than JS Doc) if you will have a build step anyway. And one question: Who is actually not using JSX for building React etc.? So that's another case where you need tools like Babel, so for me the argument with the build step doesn't really make sense, especially with more and more runtimes supporting TS out of the box (Bun and Deno from day 1 and node is getting there).
Thats if youre using a build step based frontend and not a no-build frontend like alpine or mithril. Ive been using mithril and go for almost 6 months now and it feels great just using jsdoc for linting. You get the same typesafety with no build step or build deps. This code will literally rum on the browser indefinitely with no upgrades needed.
TS has issues, sure. But going back to vanilla js is not a solution. Also if you catch yourself fighting TS, you might wanna change your mindset and think of writing TS as writing test for your code. You are literally testing code as you go, making it safer to navigate and refactor. If you still struggling, is either you are doing something wrong or something complicated and you might benefit by watching TS gurus like Matt Pocock. Writing vanilla js is easier these days exactly because you now benefit from huge TS-maps for core and external libraries. So, VScode still gives you intellisense even outside ts-modules. And even jsdocs now allow for typed parameters which is bonkers (types in vanilla is easy now). So this contrarian motion is a head-scratch honestly.
Also, your production typescript project sounds like it has serious problems. I’ve worked on multiple typescript projects for a website with millions of views each day with complicated web apps and server rendered pages, and it was NEVER that slow with its intelli-sense. I honestly have no idea how your project got so slow
It’s less about the difficulty and more of the annoyance of having to write out all of the types. It’s awesome when everything is inferred but putting a ton of generics gets annoying (co pilot does improve this tho)
You’re assigning ‘insights’ to a ternary condition of insights ? ‘true’ : ‘false’. You do that for two other keys, ‘updates’ and ‘articles’. If true, true. If false, false. I mean, it will work but why? Are you doing that to convert a Boolean to a string? There are much easier ways to do that transform without wasting runtime cycles evaluating conditions for already-known values.
these discussions around typescript are a bit useless. typescript was never made as a language, just a tool to help you. if you are comfortable writing your own million line javascript then fine, if you need a little help writing 27 lines of js without errors, use it. it is and will always be javascript. if they called it javascript-intellisense instead of typescript a lot of these discussions would have been prevented. the typescript compiler is a beautiful piece of software but it is a tool, nothing more, nothing less... there are no typescript developers, only javascript developers.
@@bmdavis419 my comment wasn't meant as critique to you. I enjoy your videos. I'm afraid that for new developers things will get a bit confusing. Now it's typescript you say, in a few months do without... Stick to Javascript because thats what is it... Keep up the nice videos and thank you for being nice about my shitty comment :-)
Typescript is a *breakable abstraction* on top of an already complicated language. It was never statically typed, it was always maybe typed code that transpiles back into javascript and I bet you don't even know how. You can use intellisense, nobody is preventing you from doing it. You can even throw a juicy jsdoc on top of that. Development can be easier with tools that eyeball your codebase, it is also guaranteed to be easier if you know the end result of you code by writing straight javascript.
Each developer has its own world of experience and it's allright if you want to code in whatever language. From my point of view, if you think that removing lints, type safety, LSP autocompletion and accepting the javascript dogmas puts you in a better dev experience, for me it talks of the code smells of that particular project, not that TS is bad or JS is "easier to work with". There is a reason why newer languages keep adding developing features like standard formatter (go), better compilers (rust) and memory safety (zig)
The title to me sounds like personal torture. TypeScript is a crutch for me at this point.
Try C# and you'll see why TS is an abomination.
Refactors or basically all cases of maintaining legacy code are the biggest reason to use typescript for me. So while you might be faster developing a new feature, if you ever have to touch it again, it'll take a lot longer without types.
Unstrict type is a FEATURE. It’s incredibly useful, especially in functional inputs.
No, it's a Warranty of hard to maintain code, especially large codebases that must endure for years and be developed by a team.
10:33 You don't need js/alpine for that, it can be done with just checkbox and CSS.
10:44 - That adding and removing of a class onclick is a simple single line of vanilla JS. The checkboxes are also very easily styled. You don’t need ANY frameworks for that. None.
People don't know how their code works.
Pardon me? 6:34 pocketbase isn't SQL? It is! It is not a document DB. It is powered by SQLite!
Btw if the editor was slow to display intelliSense it is due to Typescript LSP being notably bad. It is not an issue in TypeScript itself.
You could have a Rust or Golang code base having the same issue.
Htmx can do what you showed, it is not that hard at all. It is just a backend endpoint returning the html with the css and another without and each of them having htmx tag pointing Ajax to the other.
But I do agree with you. I prefer SvelteKit over raw dog Html.
And I was pro TS but I also live JS + JSDoc just for the sake of simplicity, like you said: don't loose my time pleasing TS compiler because blabla isn't this or that.
But TS also has a lot of rules to check your code which prevents some hic up. So serious, multi dev project is TS over JS+JSDoc.
Oh shit u are correct, completely forgot lol (although it does feel like a document DB when u use it)
@@RatchetXJ0461 for something as simple as toggling a class, you could also potentially use hyperscript to implement lightweight client side scripting. It pairs well with htmx and shares the same creator. Personally I wouldn't want to add in the overhead of an http request just for a small client state change
Classes are perfectly fine and I use them more often than factories.
They only become mildly strange if you build class instances out of other class instances provided by some frameworks. Then it gets a slightly longer prototype chain, wooptie doo.
"Click and change style" you can do it with CSS and label + checkbox input. Pretty simple task.
Hi, you can hit F2 to rename a column of a schema and it will save your time on finding red lines to update each old column name.
Another thing to note, I can be my own compiler. If something goes wrong and there's an error literally everything you have to do is: go to line => look around => write _debugger;_ in the most convenient spot, and run the file.
In case there's no error you should console log a couple test cases to see if the outputs are good or not. If they're not then do what I just described earlier, you know where the function is located.
It’s easy to fall into writing JavaScript when you should be writing ”typescript”. People try to make everything dynamic when that’s not the advantage of typed languages. Try to keep to basic types and reach for generics sparingly. But typescript performance issue are real. Explicit returns and noninferred types can make performance much better
if you are working with 200 lines of code that you wrote your self, sure js would be fine. make it 5 yo project with 10 maintainers then ts will become a necessity
Dude `user` is _exactly_ where you want to be using typescript. that `UserObject | null` is massively important. You probably don't know the shape of `UserObject` being that it's pocketBase, and is something they may update overtime. Second, typescript is going to make you properly handle the `| null` case. Even as small scale, those are going to help you write non-volatile code. Typescript is a _tool_. Using it and writing code to it's advantage is going to make you a better coder. Ignoring it, either like this, or with abundant usages of `any` and `// @ts-ignore` is just going to lead to runtime errors
100%, like I said in the video its a stupid simple example and in the real world I would never want to NOT have that. All my real projects use TS
I think if you are working on a project alone or with a skilled team of programmers you can get rid of typescript. But in most scenarios you will be working with a team of junior devs that will write some inificient code and a chunk of that code will be pushed into production, and here is where typescript is important.
How do you propose those same juniors manage to write "type suggested" code if they can't even write the base language?
10:30 that's literally one css class saying .border-greed { border-color: gradient() } or something like that, and one HTML based onclick function.
No frameworks. HTML and CSS. Hell you can even write the entire property change of border into that one function without any CSS files and the function is embedded right into the HTML.
Excelent video! You made really good points. Not sure if i agree with you in everything you said. But, for the most part, i think we share the same opinions. Btw, i really dig your font and vscode theme. Would you mind sharing them?
00:00 that's what I call enshitification of development.
People don't know what their computer is doing, don't even know what their code is doing, they just complete a 30min bootcamp and copy paste that one thing they learned that works ok, without knowing what to do when it breaks. Johnathan Blow said a similar thing about more low level game programmers, now imagine javascript devs.
I despise the idea of typescript because first you need to understand how javascript works and why it fvcks you up. I do, I have been writing vanilla js for 6 years. And now on top of that I have to understand what bs the typescript transpiler does and why it fvks me up *on top or in tandem with javascrip?*
This is just fancy comments with extra edge cases, that end up in an already edgy javascript code.
Hi senior frontend developer here with about 20 years experience; here is my observation that no one talks about. I’ve seen time and time again entire communities around a syntax preference become obsolete virtually overnight by a raw language’s adoption of said communities syntax features. Case in point, the down fall of jQuery back in the day.. So I keep telling younger developers that aspire to be a full stack developers; the stack shifts out from under you constantly unless you admit one simple fact.. libraries come and go, raw JS however seems to live forever.
If you're worried about people on the internet calling you names for using Class syntax, you can substitute a plain object in many instances. If you're just using the Class to contain some data and methods then the following would also work fine in Svelte 5.
export const farm = $state({
farmer : 'Jim',
animals : [
{ name: 'cow', alive: true },
{ name: 'horse', alive: false },
{ name: 'pig', alive: true },
{ name: 'chicken', alive: true }
],
kill : function(animal_name){
let x = this.animals.find(animal => animal.name === animal_name)
x.alive= false
},
getOwner : function(){
return this.farmer;
}
})
You don't need to use the 'function' syntax either, you can just write
getOwner(){
return this.farmer;
}
But I prefer the longer syntax. Personal preference.
The Class syntax in JS is built on top of object prototypes so if you're not using any of the Class features (like inheritance) sometimes a plain object is a cleaner choice.
How did you get in to web development writing typescript? Did you already have programming experience but not web developement experience?
Yea I had done programming before hand so I had a general idea of what was going on
I think the two biggest criticisms of TypeScript are being lumped together and it's funny because they couldn't be more different
There's the folks that want to give up on types altogether, which I think is crazy. Then there's those who don't like TypeScript because it's just a linter, the types are not real and they fully disappear at runtime, which invalidates all possible type safety guarantees
At that point you could just use JSDoc and get rid of the build step
The build step is literally not adding a single extra step in the context of building an application. You already have a "build step" when you build your Next/React/Vue/SvelteKit/whatever app. Why on earth would you use 400% more characters with JSDoc? You literally gain nothing from this. I'm somewhat more sympathetic in the context of building a library, but there's literally no point dropping TypeScript when building apps.
More and more frameworks (like react with the React compiler, svelte uses a compiler too) are relying on build steps, so why not just use TypeScript for the better typewriting experience (TypeScript just looks nicer than JS Doc) if you will have a build step anyway.
And one question: Who is actually not using JSX for building React etc.? So that's another case where you need tools like Babel, so for me the argument with the build step doesn't really make sense, especially with more and more runtimes supporting TS out of the box (Bun and Deno from day 1 and node is getting there).
Thats if youre using a build step based frontend and not a no-build frontend like alpine or mithril. Ive been using mithril and go for almost 6 months now and it feels great just using jsdoc for linting. You get the same typesafety with no build step or build deps. This code will literally rum on the browser indefinitely with no upgrades needed.
TS has issues, sure. But going back to vanilla js is not a solution.
Also if you catch yourself fighting TS, you might wanna change your mindset and think of writing TS as writing test for your code.
You are literally testing code as you go, making it safer to navigate and refactor.
If you still struggling, is either you are doing something wrong or something complicated and you might benefit by watching TS gurus like Matt Pocock.
Writing vanilla js is easier these days exactly because you now benefit from huge TS-maps for core and external libraries. So, VScode still gives you intellisense even outside ts-modules.
And even jsdocs now allow for typed parameters which is bonkers (types in vanilla is easy now).
So this contrarian motion is a head-scratch honestly.
JS for simple apps, definitely
Also, your production typescript project sounds like it has serious problems. I’ve worked on multiple typescript projects for a website with millions of views each day with complicated web apps and server rendered pages, and it was NEVER that slow with its intelli-sense. I honestly have no idea how your project got so slow
Zod I think
what about exclude node_modules as TS is permanently checking (monitoring) all files.
@@bmdavis419 We use Zod, it’s fine
I’m surprised you have issues with typescript in a world with LLMs. They just make it so easy
It’s less about the difficulty and more of the annoyance of having to write out all of the types. It’s awesome when everything is inferred but putting a ton of generics gets annoying (co pilot does improve this tho)
10:20 you could just use javascript lol
I say this as a sveltekit stan though, I would never use go + htmx, but if I did… I would just use js for little dynamic UI
True, it’s admittedly a kinda weak example I need to try out htmx fully to get a better side by side
You’re assigning ‘insights’ to a ternary condition of insights ? ‘true’ : ‘false’. You do that for two other keys, ‘updates’ and ‘articles’. If true, true. If false, false. I mean, it will work but why? Are you doing that to convert a Boolean to a string? There are much easier ways to do that transform without wasting runtime cycles evaluating conditions for already-known values.
lol I forgot u could convert a Boolean to a string, good call
maybe you should try elixir before they have types lol
these discussions around typescript are a bit useless. typescript was never made as a language, just a tool to help you. if you are comfortable writing your own million line javascript then fine, if you need a little help writing 27 lines of js without errors, use it. it is and will always be javascript. if they called it javascript-intellisense instead of typescript a lot of these discussions would have been prevented. the typescript compiler is a beautiful piece of software but it is a tool, nothing more, nothing less... there are no typescript developers, only javascript developers.
I agree, its just become a very common topic online so I figured it was worth talking about. I'm very pro-typescript
@@bmdavis419 my comment wasn't meant as critique to you. I enjoy your videos. I'm afraid that for new developers things will get a bit confusing. Now it's typescript you say, in a few months do without... Stick to Javascript because thats what is it... Keep up the nice videos and thank you for being nice about my shitty comment :-)
Typescript is a *breakable abstraction* on top of an already complicated language. It was never statically typed, it was always maybe typed code that transpiles back into javascript and I bet you don't even know how.
You can use intellisense, nobody is preventing you from doing it. You can even throw a juicy jsdoc on top of that. Development can be easier with tools that eyeball your codebase, it is also guaranteed to be easier if you know the end result of you code by writing straight javascript.
Each developer has its own world of experience and it's allright if you want to code in whatever language. From my point of view, if you think that removing lints, type safety, LSP autocompletion and accepting the javascript dogmas puts you in a better dev experience, for me it talks of the code smells of that particular project, not that TS is bad or JS is "easier to work with". There is a reason why newer languages keep adding developing features like standard formatter (go), better compilers (rust) and memory safety (zig)
Typescript is ugly