Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using TypeScript with React

simonknott.de

Post reply on HN
Print view View original

181–190 of 195 posts

Re: Using TypeScript with React

#181

Post by Aeolun »

gambler wrote: post #77
jillesvangurp wrote: post #35

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…

>If it's tedious, you're probably doing something wrong or sub-optimal. >IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arr…

I don’t think there are any downsides to Typescript. Except maybe compilation, but you’d be bundling your JS app regardless.

Re: Using TypeScript with React

#182

Post by Roboprog »

hombre_fatal wrote: post #178
Roboprog wrote: post #171

Earlier quoted context omitted.

The fact that you wrote a function called “getValue” screams “Java programmer!”. Ordinary js, like C# and some other languages, has accessors so you just use the property name as an r-value (or l-value). https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Why pick on a contrived example? You can fill in your own less-contrived state + methods, it's not really the point of their question.

As an example of the “OOP according to Java (and C++)” culture that is making JavaScript tedious to work in.

I want move past the “bad OOP” stuff shoved down my throat 30 years ago, into a style that is more FP oriented.

Re: Using TypeScript with React

#183

Post by jillesvangurp »

deviantfero wrote: post #165
jillesvangurp wrote: post #35

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…

How do you suggest someone should proceed if an essential library in their project has no typing for typescript?

Lose it or fix it (e.g. by writing some type definitions). If either is infeasible, put a fence around it and surround it with some layer. Most common libraries have type definitions at this point. The better ones actually maintain those themselves.

Re: Using TypeScript with React

#184

Post by jillesvangurp »

shriek wrote: post #156
jillesvangurp wrote: post #35

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…

Isn't it slower than node during compilation time though? I understand that there's a slight overhead on the initial setup of it already which I can plow through it but the hit on performance would be concerning cause there's already an overhead of webpack transpilation.

It adds maybe a few seconds overall maybe. Mostly it's a non issue. Webpack is slow in any case.

Re: Using TypeScript with React

#185

Post by lifeisstillgood »

hombre_fatal wrote: post #179
lifeisstillgood wrote: post #148

I just want to stop using JS on the browser side. We can compile C to WASM, which gives us effectively most dynamic languages on the browser. Say Python. I have a plan to put a tiny web framework together just having Python doing the front end stuff. Not react or anythng but enough for "most" use cases (I know I know) But JS just feels like it changes too fast, its been well over a decade of wheel-reinventing when th…

Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates. Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.

I disagree.

JS should be like SQL - everyone's second language and a standard that can be taken from job to job and company to company and still be effective.

But while I this week used my decades old SELECT skills for a quick two day job, I have also been utterly stumped trying to modify react codebases.

JQuery is probably the closest thing to SQL in the JS world and it is fine - but there appear to be few technical reasons not to use it and lots of fashion reasons.

And so while I could just stick to JQuery and some widgets, the weight of development seems to be in the morass of change that is so very hard to stay on top of.

Yes this feels like crotchety old timer moaning, even to me. But there is something there. I am having trouble expressing it however.

Re: Using TypeScript with React

#186

Post by hombre_fatal »

lifeisstillgood wrote: post #185
hombre_fatal wrote: post #179

Earlier quoted context omitted.

Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates. Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.

I disagree. JS should be like SQL - everyone's second language and a standard that can be taken from job to job and company to company and still be effective. But while I this week used my decades old SELECT skills for a quick two day job, I have also been utterly stumped trying to modify react codebases. JQuery is probably the closest thing to SQL in the JS world and it is fine - but there appear to be few technical…

Client development was never trivial. Your old iOS/Android skills also expire due to SDK changes. Apple recently switched out the entire language you're using.

I don't think SQL is a great example either. Your next company could be using any database where you aren't even writing SQL. And you're expected to know more than standard SQL to, say, use Postgres. Your rant here to me is like getting mad that "just SQL" isn't enough because you constantly have to learn more at your next job that uses Postgres, DynamoDB, etc or that "just " isn't enough because your next job uses a different framework than you're used to. I don't think your rant is consistent, so it just comes off as confused anger towards JS client development.

Maybe you don't have the stomach for client development where code must run on a machine you don't control? That isn't a disparaging remark either, it's very reasonable to prefer the cozier environment of writing code for machines you do control (like application servers).

Re: Using TypeScript with React

#187

Post by skn0tt »

mosdl wrote: post #180
skn0tt wrote: post #150

Earlier quoted context omitted.

I see why you're missing an explanation on why classes should be avoided. In fact, your opinion is very similar to mine - I also think that, especially in the context of the FP-influenced React, data should be separated from behaviour - I mean how exactly are you going to preserve immutability using OOP? React just works a lot better when there's no self-mutating objects. Could you elaborate on why you think that cla…

Any method that mutates returns a copy, pretty easy to preserve immutability in OOP.

Then what do you do about the old version of the mutated object? There will still be references to it in other parts of your object model, which will now be out of date. I think that the concept of objects preserving identity is central to OOP, which simply contradicts immutability.

Re: Using TypeScript with React

#188

Post by loceng »

loceng wrote: post #174
aficiomaquinas wrote: post #140

Earlier quoted context omitted.

> Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arrogantly spout their opinions about system design as if they had been correct about everything all along. Not "these are the benefits, these are downsides" not "I've improved in X by using Y", always "nobody needs X, everyone must do Y, and if you're not doing Z you're wrong and unprofessional".…

Humour's not allowed on HN.

Clearly whoever downvoted me doesn't like dry humor, either.

Re: Using TypeScript with React

#189

Post by lioeters »

eropple wrote: post #63
verttii wrote: post #59

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

I feel almost the exact opposite: TypeScript is delightfully terse while still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript. You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nas…

Purify does look great, I can't wait to start playing/working with it.

For reference, here's the home page and documentation for purify-ts.

https://gigobyte.github.io/purify/

https://gigobyte.github.io/purify/getting-started

Re: Using TypeScript with React

#190

Post by mbo »

sli wrote: post #90
lhorie wrote: post #85

Earlier quoted context omitted.

The problem IMHO is the old adage of the devil being in the details. I see a lot of engineers talking about things like deriving types from enums, and meanwhile the type system will merrily let you do this: type Foo = {a: number} const o: Foo = JSON.parse('null') o.a = 1 It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilitie…

I've run into issues with TypeScript that forced me to cast string literal types to themselves before it would compile. So literally this code: 'x' as 'x' Nothing else would work, we were simply forced to do that. Avoiding `any` in all cases is simply not possible, as Redux will require you to use it at least once as of the last time I used TypeScript, which wasn't that long ago. Type discoverability for libraries wa…

TypeScript does not have higher-kinded types. I'd link sources but it's difficult to prove the negative here. It just doesn't have any.
Post reply on HN