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

How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

chiragswadia.medium.com

Post reply on HN
Print view View original

381–390 of 400 posts

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#381

Post by seph-reed »

selfmodruntime wrote: post #282
seph-reed wrote: post #168

Earlier quoted context omitted.

I've spent the last two years writing my own framework because I hated React so damn much. It really doesn't have to be that complicated. Granted, I still use a bundler, but it's really easy to set up. I had my friend walk through it all... he seems to think it's great. I should probably release this project some day.

Why did you hate react? It‘s really one of the less complicated frameworks out there.

It doesn't use native elements, and instead goes from React Components -> HTML Text -> Native Elements. So then the moment you have two elements interacting it falls on its face. Like forms.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#382

Post by blacktriangle »

smnplk wrote: post #358
blacktriangle wrote: post #216

Earlier quoted context omitted.

Clojurescript is the worst offender on that list from the point of view of "needlessly complicated." I can't imagine a dependency I want less than the Google Closure tools. I swear Closure is probably the only tool with fewer devs who understand it than autoconf. I'm not critiquing any of those languages, in a perfect world any of them in the browser would have been preferable to Javascript. The issue is the tower of…

With advanced optimisiation turned on, the Clojurescript compiler will not include any of the Closure code that you do not use. But my point was about language superiority. For me it's obvious why Clojurescript wins the client side.

My issues is not the runtime dependency but the development dependancy. As the production apps I am responsible for keep getting older and older my opinions on ruthlessly cutting decencies get stronger and stronger.

Somewhere there's probably an optimal expected lifespan of a program where the line between preferring a better language and fewer development dependencies is crossed, but I'm also starting to learn that software stays around years longer than I ever anticipated.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#383

Post by seph-reed »

abraxas wrote: post #323
seph-reed wrote: post #168

Earlier quoted context omitted.

I've spent the last two years writing my own framework because I hated React so damn much. It really doesn't have to be that complicated. Granted, I still use a bundler, but it's really easy to set up. I had my friend walk through it all... he seems to think it's great. I should probably release this project some day.

Any reason you forged your own versus adopting Svelte or Alpine? As a fellow React hater I'd love your take on those lighter frameworks.

It started off as just a shorthand tool for creating elements:

``` div("ClassName", { childNodes: [], etc: {} }); ```

Then it grew into having a state management system. And now it's easily the best framework I've ever used... super fast, light weight, extremely malleable, easy to understand.

I keep intending to release it, but I know just how much fun it is putting something out in the world... I don't want this project to turn into my life.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#384

Post by cryptica »

macspoofing wrote: post #369
cryptica wrote: post #333

Earlier quoted context omitted.

This is incorrect. This is just repeating popular rhetoric. Well designed projects are broken up into manageable, individually testable modules... So codebase size is an anti-pattern to begin with. As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? What about having to type up all these extra type definitions? You could have spent that time writing…

>Well designed projects are broken up into manageable, individually testable modules And JavaScript does not make it easy to do that. It also makes it very easy to do it incorrectly and in a way that is an unmaintainable mess. Every programming language can be used to write clean code if you try really hard, but not every programming language will have the syntax, semantics and conventions that will make it harder to…

>> If you do try modularize JavaScript, you're going to need a compilation chain to package it all together - so you're not getting away from that.

That's not always the case on the front end (it's still possible to code on the front end without a bundler). And it's certainly not the case on the backend (I.e. Node.js).

>> Sure it adds up, but it's a tradeoff. If you're writing a dinky little web app for your grandma, maybe that trade-off isn't worth it.

This could not be further from my own experience having gone back and forth between JavaScript and TypeScript multiple times both professionally and as part of my open source work for over a decade.

I've built highly complex scalable distributed pub/sub systems, P2P systems, blockchains and a decentralized exchange using plain JavaScript in record time with no bugs found for over a year.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#385

Post by WorldMaker »

recursive wrote: post #303
runarberg wrote: post #285

Earlier quoted context omitted.

You can use `Map` instead of object which allows keys of any type, or typecheck your objects with `Record ` and let typescript warn you about any weirdness. Typescript can also warn you if you do some weird implicit coercion. You can typeguard against `null` (although I admit it is annoying, I just want to use an optional†). And if you really want to use integer types there is always `BigInt`. --- †: I haven’t checke…

I use BigInt often, but you can't (for example) do most substring operations with it, even though floating point indexes make no sense. Map goes part of the way to what I want. But I really want to control which objects are considered equivalent keys, rather than being limited to reference equality.

There's a Stage 2 proposal before TC-39 to add immutable Record and Tuple types [1] which would be structurally compared and perfect for complex Map keys.

It's also easy enough to find or write quick simple Map wrappers that use a hash function on an object as keys when provided (either piggy-backing on the existing Object.prototype.valueOf, which always exists on every object and easily falls back to the reference-based current behavior, and expecting classes to have custom overrides for that, or using a Symbol named function of their own to avoid polluting own-property-keys/name clashes with other libraries).

[1] https://github.com/tc39/proposal-record-tuple

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#386

Post by joquarky »

jakub_g wrote: post #25
hocuspocus wrote: post #12

Are there big companies still doing untyped JS at scale out there? I'm not a frontend person and I always disliked dynamic type systems. But I vaguely remember the skepticism when Angular moved to TS. To me it made a lot of sense that most projects at Google, MS and the like would hugely benefit from a language that is kind of a C# on the JS runtime. And in 2021 I see TS pretty much everywhere, but maybe I'm missing…

In my team people object to TS due to a few things: additional complexity, additional build step, build time increase, copy-pasting code around (to console, code snippets etc.) does not work anymore (but last time we talked it was soon after coffeescript -> esmodules migration and I guess everyone was tired of coffeescript which might have affected the mood). There's no unanimous consensus that TS is all gold; some p…

> Something that's gaining popularity and what I'm trying lately is using JS + jsdoc annotations more thoroughly, which gives the niceties of TS (when using vscode) without the downsides and heavy compilation step

I'm a big fan of this as well. Webstorm also supports it.

It feels like the right balance to me, as it gives me a heads up when things don't match, but doesn't require that I go through the tedium that TS imposes once it touches a project.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#387

Post by joshAg »

eropple wrote: post #379
Shacklz wrote: post #189

Earlier quoted context omitted.

Doing runtime-typechecks really is a blessing, and it would be great if typescript would provide this as a language-feature. There are two more libraries I know which are great for that: * Zod: https://github.com/colinhacks/zod * io-ts: https://github.com/gcanti/io-ts (for the more functional-programming-oriented)

I like io-ts, but I've moved mostly to runtypes: https://github.com/pelotom/runtypes I forget why Zod didn't pass muster for me now, but I've looked at it before and didn't find a compelling reason to jump to it. Thought it seemed good, though. I really wish at least one of these let you emit JSON schema back out, though. That'd be way easier for dealing with stuff like OpenAPI.

We go the other way. We start with openAPI, use dtsgenerator to spit out typescript types, and then use a library (typescript-is) that will generate run-time type check function as part of compilation.

A downside to this is that you need to compile type changes before you can use the change in code, but it gives us a single source of truth for our type definitions and let's us generate a more exacting request and response verification functions that use the (sometimes) more precise open-api definitions (eg a an array with a maximum number of elements and specific string formats), and it's really easy to add a run-time type check to the result of calling into a 3rd party library as well.

For runtypes, you could write a script to use its Static function to spit out the interfaces in pure typescript and then use something like typeconv or ts-to-openapi to make your openapi definition, and then use that script inside your build script to output the openapi schema.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#388

Post by munificent »

spideymans wrote: post #245
munificent wrote: post #233

Earlier quoted context omitted.

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. Respectfully, its really hard for me to wrap my head around this mindset. When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types. You know the b…

> When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types.

Lucky for you. Not everyone did.

It's very hard to remember what it felt like to not know something and likewise hard to remember how hard it was to learn something once you do.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#389

Post by munificent »

spideymans wrote: post #242
munificent wrote: post #233

Earlier quoted context omitted.

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget. I don't understand how one can be a great (or even half-decent) SWE with such an aversion to learning something so common and foundational as types.

I'd be willing to bet money that if you were to list all your skills and non-skills, I could find at least one thing that you don't know that other SWEs would consider just as "common and foundational".

Could be any of: data structures and algorithms, complexity analysis, operating systems, parsing, compilers, databases, networking, user interface programming, OOP, FP, MVC, markup languages, the web, graphics, manual memory management, pointers, computer architecture, etc.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#390

Post by munificent »

rowanG077 wrote: post #256
munificent wrote: post #233

Earlier quoted context omitted.

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

This is wrong. Dynamically typed languages still have types that need to be understood by the developer. They are only checked at runtime and not at compile time.

Values have types, but variables do not. All programmers have to think about the former, but only statically typed programmers need to reason about the latter.
Post reply on HN