Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

> Surely in the end it just adds complexity and fragmentation of the ecosystem?

Lol. I switched to TS from pure JS a couple years ago and could never imagine going back. I am so much more productive in TS than JS:

1. Typeahead is crucial, and even when just working on my own projects it makes me much faster.

2. Refactoring is a scary nightmare in pure JS, but so much easier with TS.

3. I have yet to see any sizable, multi-person pure JS project not become an incomprehensible nightmare after a couple years. TS makes large codebases much easier to maintain.

There are other reasons.

If anything, the consolidation onto TS from previous competing type systems for JS (e.g. I think Flow is dead for all intents and purposes, and I've seen a number of projects migrate onto TS from Flow) results in less fragmentation.

View on HN

I understand the power of types - I just wonder why the heck you are writing so much JS/TS code?

Are you doing server stuff with it?

You could argue here there are much better languages and platforms for that.

Have you seen the size of frontend codebases? Even modest SPAs reach into the tens of thousands of lines. Or the size of large Express.js driven backends? A huge portion of the web is driven by JS/TS.

>> Even modest SPAs reach into the tens of thousands of lines.

I still don't get how we got from fifty lines of code for a form with simple client side validation to a React/Vue/Angular/Next version that needs 100 different modules and a thousand lines of code to replicate. Why do people see this as a huge advancement in front-end development?

Those libraries are providing a lot more than just simple validation though. Bunch of advanced validation rules, masking, etc. I'm sure if you dive into any of those modules you'd be able to see why. Not saying there isn't dependency bloat but it's not like people are creating these for the sake of it.

Because people are writing applications, not forms. As software engineering has gotten easier, customers have demanded more complicated applications.

Modest SPAs do have a lot of code. So does a C++ Win32 application that calls into some central datastore. The complexity is not a byproduct of languages or libraries, but rather the customer's complicated needs.

have you worked with GUIs much? complex interactive UIs take a surprising amount of code, doubly so if what you're doing isn't covered well by your platform/toolkit's native inputs.

i'm working on a webapp with a scheduling thing and even drawing a nice-but-not-interactive day schedule is a bunch of work. consider a day view that lays out overlapping events next to each other:

   Dec 8
  -----------
   9
  10  AAA
  11  AAA BBB
  12  AAA BBB
  13      BBB
  14  CCC BBB
  15  CCC
  16  
  17  DDDDDDD
  18  DDDDDDD
  19

like, even laying out those boxes takes a bunch of code. and then you need interactivity, the actual "app" part - you want drag-n-drop that snaps to columns and switches you to another day if you drag it to the side, and selections, and menus, and hovery-popupy things, and undo, and so on... it adds up quickly

But you can split it with with web components and es6 modules to be sane without resorting to a pre-processor so you code won't run directly on the platform.

Yes, in my current tech stack our entire backend is in Node with TypeScript, and the front end is React with TypeScript.

> You could argue here there are much better languages and platforms for that.

You could, but I think you'd be wrong. I come from a background of using Java on the backend for over a decade, then some time with various backend languages including Python and Ruby. This is the first time in my career when everything (front end and back end) are essentially on the same stack, and there are huge, gigantic productivity improvements to that. Most of it stems from it being easy for developers to switch between front end and back end code. E.g. it's very easy for front end developers to dig in and debug something that's not right on the back end, and usually to fix it themselves. Same thing goes for backend devs investigating how APIs are used by the front end. In all my previous jobs it was relatively rare (certainly not never but not that common) for devs to cross that divide, mainly because setting up the environment in a totally different stack was time consuming and annoying, and mentally context switching into a different language was difficult, if all you wanted to do was dig in on one particular endpoint, for example.

But even discounting that, I am much more productive in TS than I ever was with Java, primarily because the structural typing of TS makes thing much easier to refactor compared to the nominal typing of Java. Sure, there are some cases (mainly WRT scalability) where Java may be a better choice, but the idea that TS/Node is not an awesome choice for the server is outdated IMO.

>primarily because the structural typing of TS makes thing much easier to refactor compared to the nominal typing of Java.

That's interesting. This year I switched from server-side Java to server-side TS and I find that refactoring is incredibly painful when compared to Java. I think any productivity gains in the greenfield portion of a TS project are quickly offset by the pain of refactoring and debugging during maintenance. It's really disappointing, as I quite like TS.

I'm curious, could you give an example where refactoring is more difficult? I find TS much more easy to refactor because since the structural typing basically just says, for example, "This method argument needs to have these properties of these types", if I find out "Uh oh, this method actually needs one more piece of data", in Java I'd have to change the definition of the type that was passed in which could have lots more unintended side-effects, while in TS I can essentially "localize" my changes just to wherever I call that method.

The "blast radius" if you will with nominal type systems is just always much larger.

What text editor did you use before? I think the biggest advantage is an IDE, not the language itself.

As a daily user of IntelliJ IDEA—which, IME, has the best autocomplete and code suggestions of any IDE for dynamically typed languages—there is a world of a difference between the quality of suggestions for a codebase using TypeScript and one written in vanilla JS. Without concrete types, the IDE often has to guess the possible type(s) that a value can have, whereas with TS, there is (generally) no such ambiguity.

I don't really experience this issue and I use Web storm which is basically the same thing. I find that the dynamic type hinting plus the combination of using JS Doc formatted comments rarely leaves me with any ambiguity when writing vanilla JavaScript.

Are you using types in your JS Doc comments? If so, that's not vanilla JavaScript.

JS Doc is just comments. (But the typechecker can still read them.)

It is because it runs in the browser unprocessed.

You edit a file and reload, no munging pipeline,

Reply on news.ycombinator.com