111–120 of 244 posts
The type system is a little bit more advanced than those languages with nominal type systems like Java. Sometimes typing old code is tricky. But the good news is you can escape by using any anytime.
> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.
This. I always focus more on the "foundation" part, in this case, it's common React Hooks and its API for the components to use. The good part is, if some hooks are wrong, we can just write new one and replace old ones within old components without the need of taking care of the old wrong Hooks.
Earlier quoted context omitted.
I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!" This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've ne…
I think it depends on what you're engineering. For example, adding static typing to a language has immediate gains regardless of code base size. It is also low risk and easy to implement. Designing a spring quartz scheduler backed by a DB when a simple cron job would do? That's overkill.
I say that half in jest but one of the dumbest & most destructive things in software engineering is tribalism or militant belief systems. Having a “neutral” way to deal with them (or something like “data” seeming like it’s neutral) once and for all does wonders for productivity
People who don’t like or trust typescript, what’s your good-faith case against it. Personal productivity or ugly/confusing syntax are valid reasons I think
I've also found it easier for new developers to become productive sooner when the language and framework guides them in the direction they want to go. I'm all for anything that supports a positive developer experience, and it's more concise to express my design in terms of static types than it is through mounds of documentation or exploring the code.
Here's some thoughts on what has contributed to that so far:
1. TypeScript pushes you towards its own build pipeline (based on tsc) that doesn't play nicely all the time with mainstream JS build pipelines (usually based on babel).
With babel 7 came @babel/preset-typescript, which I hoped would narrow the gap, but so far it's very clearly a second class citizen in the TypeScript ecosystem, with new features built only with tsc-based pipelines in mind (Project References is the one that stands out because we sorely need it for our monorepo codebase, but can't use because we chose to adopt @babel/preset-typescript), and having personally ran into several issues stemming from what seems to be fundamental incompatibilities between tsc and babel that have no real workarounds (here's one that I can remember off the top of my head: https://github.com/babel/babel/issues/8361).
The reason this is so frustrating is TypeScript could have been just a type checker, like Flow. But instead, it had to introduce it's own compilation tooling which is still vastly inferior to babel in terms of overall flexibility and extensibility. All of this seems to be due to what I believe are a few fundamentally poorly thought-out decisions at the beginning of the project to allow TypeScript to specify its own language features that have runtime semantics (things like Enums and class visibility modifiers, neither of which are anywhere close to becoming standardized in JS-proper, by the way, and both of which are completely orthogonal to TypeScript's main responsibility of type checking), and implementing them using a separate build pipeline instead of as extensions to babel & its own type checker.
If I were to use a JS type system for a new project today, I'd personally choose Flow over TypeScript in a heartbeat because of this.
(this is getting a bit long so will continue in a reply)
Earlier quoted context omitted.
This. I always focus more on the "foundation" part, in this case, it's common React Hooks and its API for the components to use. The good part is, if some hooks are wrong, we can just write new one and replace old ones within old components without the need of taking care of the old wrong Hooks.
Aren't Hooks too new for you to make claims about what you "always" do with them?
Isn't anyone worried that TypeScript will go the way of CoffeeScript?
I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.
Try building an app in ES3 JavaScript (i.e. it has to support IE7 with no transpiling) if you haven’t before. It can be rather frustrating if you’re used to modern features.
Prototype.js was the kick that eventually led to the standard library updates in ES5, and (as another post has said) CoffeeScript was the kick that eventually led to language- and syntax-level updates in subsequent versions.
I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional programming context. — this is one of its best strengths in my opinion, and one reason I now prefer TypeScript over C#.
This doesn't seem like a common occurrence, judging from all the praise of TypeScript sung on this thread and elsewhere, but I've had an overall negative experience working with TypeScript so far. Here's some thoughts on what has contributed to that so far: 1. TypeScript pushes you towards its own build pipeline (based on tsc) that doesn't play nicely all the time with mainstream JS build pipelines (usually based on…
I do agree on the extra stuff beyond types (enums, etc) being a mistake that Typescript would be better off deprecating at some point.