191–200 of 257 posts
Earlier quoted context omitted.
Often because the "standard" thing was not always the standard. Like, all those people that chose Flow now have something "non-standard."
Coffeescript used to be "standard" in Ruby on Rails community. (insert canned laughter)
Earlier quoted context omitted.
It is actually a fairly indicative story. At the start there is a brilliant individual (Evan) who sets up an entire toolchain + core of the product. They then move on (or get pushed out, or get bored), and with the team (and the product) now being much bigger, things get replatformed to a more familiar, widely used stack. The success of these steps heavily depends on how robust the eng culture is at the organisation.…
It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased. Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience.…
I’ve done Webpack configurations and Browserify before that. I’ll be glad if I never go there again.
Earlier quoted context omitted.
Some people also hate parking between the lines and returning shopping carts at the grocery store. Those are similar in that they have negative value to the individual but help the community around them. TS often can interrupt an individual's flow, so feels like a negative value. It's only when the whole team is using it on a bigger codebase with lots of changes that the benefits start to manifest.
Imagine you come from a small town where there are no parking lines at all, and everyone efficiently parks on unmarked blacktop in a respectful way. Now imagine you go to a big city where they have a bunch of lines in the parking lot and people only half use them correctly, parking over the lines, diagonal, etc. The existence of lines doesn't guarantee good behavior. The absence of lines doesn't guarantee bad behavio…
You're dreading javascript
Earlier quoted context omitted.
I manage a relatively junior developer who has been using ts ignorer statements a couple of. times. I have said to him, that everytime he feel inclined to either use ts ignorer or do type coercion, he should call me first. every single time it is a reasoning flaw implementing a solution that is sub par and bug riddled. Had they just let types guide them, they would have become better developers and not had broken the…
Duck typing can lead to a false sense of security when you /think/ you have Foo when in reality you have Bar with the same shape. Also Typescript sucks at keeping track of type changes in a single scope. While in Rust I can assign string to foo and then update it with int, I can't in Typescript. This leads to worse types or worse code for the same operation. Combined with typescript's lack of statements as values, co…
Earlier quoted context omitted.
I manage a relatively junior developer who has been using ts ignorer statements a couple of. times. I have said to him, that everytime he feel inclined to either use ts ignorer or do type coercion, he should call me first. every single time it is a reasoning flaw implementing a solution that is sub par and bug riddled. Had they just let types guide them, they would have become better developers and not had broken the…
Duck typing can lead to a false sense of security when you /think/ you have Foo when in reality you have Bar with the same shape. Also Typescript sucks at keeping track of type changes in a single scope. While in Rust I can assign string to foo and then update it with int, I can't in Typescript. This leads to worse types or worse code for the same operation. Combined with typescript's lack of statements as values, co…
This is literally always your problem with javascript, its only sometimes your problem with typescript. It's a weird argument.
> Also Typescript sucks at keeping track of type changes in a single scope.
Isn't this considered a very bad practice? Also rust does not allow this, it only allows shadowing.
> Combined with typescript's lack of statements as values, conditionally initializing a value is pretty obtuse.
Can you give an example?
Earlier quoted context omitted.
Some people also hate parking between the lines and returning shopping carts at the grocery store. Those are similar in that they have negative value to the individual but help the community around them. TS often can interrupt an individual's flow, so feels like a negative value. It's only when the whole team is using it on a bigger codebase with lots of changes that the benefits start to manifest.
Not just with teams, going back to a solo project after some time is so much more of a hassle if you don't have any types to guide you.
I rewrote one of those projects in Typescript a while back, and came across a similar "clever" solution (mainly having to do with dates having potentially multiple sources, so being in potentially multiple formats), and it made the code _infinitely_ easier to understand. So much so that when I came back to it recently, one quick glance at the types for that section of code gave me all the information I needed to confidently extend that code without worrying about bizarre runtime errors.
People forget that even in single-person teams, you're actually working with many different "people" over the lifetime of the project, given how different you and your understanding of the context of your code will be over time.
Earlier quoted context omitted.
It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased. Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience.…
You don't have to transpile anything, you can just put your TS types in JavaScript comments. Or am I missing something?
Earlier quoted context omitted.
Some people also hate parking between the lines and returning shopping carts at the grocery store. Those are similar in that they have negative value to the individual but help the community around them. TS often can interrupt an individual's flow, so feels like a negative value. It's only when the whole team is using it on a bigger codebase with lots of changes that the benefits start to manifest.
Imagine you come from a small town where there are no parking lines at all, and everyone efficiently parks on unmarked blacktop in a respectful way. Now imagine you go to a big city where they have a bunch of lines in the parking lot and people only half use them correctly, parking over the lines, diagonal, etc. The existence of lines doesn't guarantee good behavior. The absence of lines doesn't guarantee bad behavio…
But if you have a dev team that is taking the time to efficiently park in a respectful way, if you paint lines, _you're going to make that parking job a hell of a lot easier to do!_ And THAT's the big win of Typescript.
Earlier quoted context omitted.
Some people also hate parking between the lines and returning shopping carts at the grocery store. Those are similar in that they have negative value to the individual but help the community around them. TS often can interrupt an individual's flow, so feels like a negative value. It's only when the whole team is using it on a bigger codebase with lots of changes that the benefits start to manifest.
Imagine you come from a small town where there are no parking lines at all, and everyone efficiently parks on unmarked blacktop in a respectful way. Now imagine you go to a big city where they have a bunch of lines in the parking lot and people only half use them correctly, parking over the lines, diagonal, etc. The existence of lines doesn't guarantee good behavior. The absence of lines doesn't guarantee bad behavio…
For the record I don't like the syntax either. Combining ES type spreading with TS type annotation makes for difficult reading in my opinion. Why settle for this bastardized language and not just compile something made to be strongly typed into js?
Earlier quoted context omitted.
That is really unfortunate. Webpack is a nightmare and outdated. I wonder how you came to use it? Node has a nice intro: https://nodejs.org/en/learn/getting-started/nodejs-with-type... (skip ts-node and go directly to tsx). Or Deno or Bun run your TS code directly. Modern frontend frameworks like Vue or Svelte have their own tooling, mostly based on Vite and Esbuild. I think it was just bad luck that you came across…
I know you're trying to help, but this further highlights the problem with frontend dev.
They do fundamentally the same things but with very different approaches and tradeoffs.
Webpack and Vite are very different approaches to the same problem with different tradeoffs[0][1]
[0]: namely, webpack and its inevitable successor rspack, are way more flexible and arguably powerful but at the cost of higher complexity and more proprietary features like the webpack/rspack specific runtime. Superior in asset handling though, in many respects, and the high level of optimizations you make once you hit a certain complexity threshold is greater than what Vite/Rolluo has currently without extensive custom plugins
[1]: Vite or Rollup is most likely what most projects need. I’d recommend always starting there, as most of the advanced and flexible features of webpack/rspack are very much not what most need