5 ms·
I have to disagree with the Typescript part. Granted, it's not a bad suggestion, and there's a lot that's good about TS, but this isn't what I would consider a
by ravenstine 4y ago
I have to disagree with the Typescript part. Granted, it's not a bad suggestion, and there's a lot that's good about TS, but this isn't what I would consider a good place for it for a few reasons.
TS, in my experience, has limited benefit when it comes to building a UI, and frontend JS is heavily married to UI programming. For guaranteeing UI functionality, writing years is a better use of one's time. What's more important with UI development is the ability to change visual components fast, and TS often gets in the way of that because it's strict as a feature.
Someone who is deep into TS may have the experience such that they are an exception, and can really benefit from using TS across the board. Since the OP is asking for a frontend framework, I would not assume they are one of these exceptions.
Where TS really shines, IMO, is in business logic and library code, because that's where concrete expectations and promises typically lie. TS is also really good for writing backends for similar reasons.
This might be most appropriate for the OP:
Frontend: Some TS for logic that's well separated from the UI, but don't try to make TS work within code that is rendering stuff. Major frameworks put in lots of effort to support TS in the view layer and, with some exceptions, it usually comes with caveats
Tests: Use JS. Your tests should not be an app in and of itself.
Shared libraries: Use TS only if you prefer it or if other entities are using it, in which case TS helps your code fulfill it's promise to third parties.
And if the OP really ends up hating Typescript, then they should just not use it. TS is not a requirement.
- iainmerrick 4y agodon't try to make TS work within code that is rendering stuff. Major frameworks put in lots of effort to support TS in the view layer and, with some exceptions, it usually comes with caveats I’m really not sure what problems you have in mind here. I’ve found TS to be really useful with very few caveats. The biggest problem you’re likely to hit in TS is when things subtly lose their strong typing accidentally -- for example, you need to use some API that works with untyped JSON blobs. But the you’re no worse off than if you were just using plain JS in the first place. TS is especially great when you’re using libraries with good type annotations -- your IDE can give you useful live typechecking and autocompletion, even if your own code is in JS! In React code, TS is really good because you can statically check your prop types. There is a little bit of a learning curve to doing that both correctly and tersely, but I think it’s more than worth the effort. As the OP specifically said they wanted strong typing, TS seems like an obvious choice over vanilla JS. I suppose you could consider other things like Flow or Reason, but TS is the most widely-used by far.
- deleted 4y ago[deleted]
- matthewwolfe 4y agoOP literally mentions that weak typing is a deal breaker, so they should definitely use typescript.
- ravenstine 4y agoHonestly, I did not catch that part. I still think it's a poor idea, but that's only my opinion. If they really don't want weak typing, then yeah, TS it is.
- threatofrain 4y agoFor personal projects you should learn how to make TS shut up. I’ve found TS useless on the front end for many places… but for state and utility libraries it’s nice. Hence don’t aim for complete strictness.
- ravenstine 4y agoThat's a good point. TS is still very helpful for catching things before build time, but I don't always want it to actually stop me from doing certain things (which I know can be overridden but that takes more actions).
- cercatrova 4y agoSorry, I have to disagree. I used React before with JS and moved to TS, and the difference is just night and day. Forgot a prop? Wrong parameters in a function? Forgot to import a component? TS catches all these while JS doesn't. What problems specifically do you have with TS on the frontend?
- dccoolgai 4y agoSpot on. 3 years ago I threw a huge tantrum and almost quit my job because they forced us to use TS. Today, I would never code for more than myself without TS. I see it really as more of a "contract system" than a "type system" and that's the real subtle genius of it.
- MrRiddle 4y agoThere is not reason whatsoever to use JS over TS for UI. None of the things you said are true.
- chaos_emergent 4y agoI agree with you - with the premise of many years of development JS is a much better fit for manipulating the DOM. ClojureScript also accomplishes an isomorphism with what it represents under the hood while being dynamically typed and it seems like people enjoy that DX too. For a beginner, my experience is that TS is a good way of discovering and working with the complexity and feature set of HTML and web browsers.
- JoeyJoJoJr 4y agoIMO if you are using React, you absolutely should be using Typescript for UI on non-legacy codebases. There is most certainly a learning curve in understanding why Typescript seems to show you errors in your UI code, but once you understand the ~5 most common errors it becomes much, much easier to use Typescript instead of JS. I simply won’t use React components (or other libraries for that matter) from NPM if they don’t have Typescript typings (or if I can’t easily create an abstracted shim over the untyped code). The benefits to using Typescript are immense.
- runald 4y agoStrongly disagree. TS is very useful for UI, among other things, especially for lots of throw-away or prototype code that changes fast quite often. TS makes it really painless to move and change things around, as opposed to plain JS where things will break quite often on runtime.