Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’ll argue further suggesting Typescript has added to the too much syntax conundrum. Modern JS looks nothing like sensible syntax, and we are definitely in the realm of C++.

But alas, no one ever listens in JS. They just add more and more shit until things are unrecognizable.

People hate plain JS so much, that they’d rather mutilate into the language they prefer, and people are coming from every corner of programming with every type of preference (pun).

One of these days I’m going create a barbarian horde of JavaScript developers and inundate another language, maybe Java, maybe Ruby or Python, and just vehemently insist that they must change their idiomatic style to that of Javascript. Let’s see how they like it.

Anyone know why we have 30 imports at the top of each file like it’s Java? Where did that idea come from? Excessive types, huh? Since when? Have mercy on us, please.

Edit:

These were the welcome and necessary changes IMO:

JS just really needed Classes as syntactic sugar for the odd way we replicated it with prototypes. That and the fat arrow (because binding ‘this’ was cumbersome), along with a basic import statement. Destructuring I can live with. Async/await was also necessary. We really didn’t need shit else.

Small exception:

I’ll make a veery small exception for a minimalist type system, or in other words, only 10% of typescript. I’ll take just the ‘Type’ and that’s all.

Last note:

Coffeescript did a better job synthesizing JS with ideas of other languages compared to ES6 honestly. Sometimes you have to think about how things mix/fit rather than ‘oh this language has it and JS doesn’t, so let’s add it’.



As someone who had the pleasure to write plain JS since, say, 2003, I greatly welcome all these changes that make JS less repetitive and easier for writng the correct thing.

And JS codebases are so much larger than in 2003 that the old idiomatic style is just unproductive.


> I’ll make a veery small exception for a minimalist type system, or in other words, only 10% of typescript. I’ll take just the ‘Type’ and that’s all.

All we should have are primitive types like object, number, string, boolean, undefined. Anything else should just define a shape/interface of an object, but no "type" that can be inherited.

In that case, as you say, 90% of Typescript could go away and be relatively straight forward.

> JS just really needed Classes as syntactic sugar for the odd way we replicated it with prototypes.

Depends on if that's actually odd. In my opinion, we should avoid prototypes most of the time, so it's strange in retrospect that we layered a cumbersome OO construct on top of it without any of the benefits other languages have like being able to change the constructor/initializer method after class construction.

> We really didn’t need shit else.

Yep. Sadly the older I'll get the more crystalized that realization will become and the more frustrated I'll be at a world that thinks more is better.


“10% of TypeScript” sounds like words uttered by someone who has never used typescript. Strictly typed programs are incredible. My UIs never crash anymore


I disagree. I didn’t start programming with Javascript, in fact I started with your typical compiled languages that literally need types to allocate memory. Even in those languages, I haven’t seen that kind of excessive use of Types that I see in Typescript. I’d love for more people to chime in on this because I was taken aback at how exhaustively Typescript is used by the JS community (different from widespread use, I mean people are literally going overboard with how far they are going with the type system).

I’m advocating for a tighter, more minimalist language. It’s not what you put in, it’s what you leave out, remember?


What kind of programs do you develop in JS? I don't think the kind of low-level programs that are allocating their own memory are anywhere near the same world that JS UIs are, and TS really helps solve JS UI problems like deeply nested JSON access, fully-typed state transitions, and manipulation of component interfaces (i.e. passing partials around so the "user" controls labeling while the component's developer wired functionality).

What parts of TypeScript are you finding would impart more value by having been left out? For example, I find it extremely expressive, and I have gotten huge value out of things like accessing return types of functions, aliasing the non-nullable types in a union type, creating sub-types of massive JSON structures via `subtype = MyType["mySubField"]`, Partial/Pick, Exclude/Omit, ... What things have you seen that you don't understand the usage for?

Final question: what is the most sophisticated UI component you have ever implemented? For example, I regularly implement what are sometimes referred to as "dataflow editors", so maybe this helps explain why I see value in the more niche sides of TS while you come in and decry the construct entirely


I don’t know anything about what you are working on, if you say it works for your specific use case, fine. A better question for you would be, do you believe you could not write that UI if Typescript didn’t exist? You’d be able to, but I know you’ll argue ‘but it would be much more painful’.

Maybe, maybe not. But to entertain you, if the breadth of Typescript solves your niche needs, do you believe most UIs require that same exhaustive usage? Because that’s what’s happening, I’ve seen very simple things overusing it.

I don’t have much more to say about this, but happy to hear your last word.


> I don’t know anything about what you are working on, if you say it works for your specific use case, fine. A better question for you would be, do you believe you could not write that UI if Typescript didn’t exist? You’d be able to, but I know you’ll argue ‘but it would be much more painful’.

I worked on a team that happened to be starting on a cross-platform React Native app that needed to have its business logic able to be re-used on a couple other platforms that weren't well-supported by React Native (or React), but did support JS well enough, when we decided to trial TypeScript. The team had done a bunch of "apps" in React and a couple in React Native without TypeScript, before this.

TypeScript made things so much nicer. It cut necessary communication overhead during development down to almost nothing. Turnaround on platforms that were slow to deploy to was a non-issue because things almost always worked on the first try. Navigating the codebase was downright pleasant. Refactoring a library that was used by multiple platforms, a breeze. Simply excellent.


I am working on various UIs for data manipulation & visualization.

> Do you believe you could not write that UI

No, I wrote these UIs in bare JS and React before, using class-based components and old react state or mobx. I also maintain a library of components because I generally write multiple UIs simultaneously, which of course can use the same building blocks. Since React Hooks & TypeScript, my component library lost about 40% of the LOC (after adding type definitions), looks much prettier, and is infinitely more discoverable with type annotations and autocomplete on everything.

So, do I need it? No, you arguably never need type systems. But the developer experience is an order of magnitude smoother. I option-click into any component when I need to understand its type interface, and I don't need to read any code to do that! I also can seamlessly use graphql-codegen.

But maybe more to the point:

> I’ve seen very simple things overusing it

This is true of every construct, ever, do you not think? People are not inherently good programmers.

Ultimately, I admit that TypeScript and JS have design flaws and non-minimalist features that you can attribute to "dumb evolution" (i.e. people adding features here and there to JS, TS trying to ensure all sorts of JS are covered, TS trying to make sure you can handle all existing types of JS with TS, etc.). However, given the context being that JS & React/JSX are the dominant UI language for web, TS solves this use-case cleanly and with a great level of expressiveness. It is huge and can be overwhelming, but it's important to remember you don't need to use any of these things, and there isn't really. any sort of interop-gulf around TS either (i.e. someone exports a type, you can interact with it, no questions asked).

So, is it graceful from an idealist perspective? No, I concede this. However, it is a tool I would never again turn away from, and while I wouldn't necessarily say it enables me as an individual to do new things, I think it makes it possible to program ideas of high complexity and allow others to work with it much more easily than just JS, which enables me as a team member to boost my teammates.


> I’ll argue further suggesting Typescript has added to the too much syntax conundrum

Shit like:

    const [,, { name }] = props;
Is part of why TypeScript's practically necessary in modern JS, if you don't want to go insane and/or let a bunch of stupid bugs sneak in.


Or people could just not write shit code. No idea why expecting basic competency with the language you're using is so out of vogue these days.


Reading one of your dependencies to track down a bug, and finding that they've written it using a totally alien subset of the language that you don't use, is not a lot of fun. The JavaScript community in particular both loves dependencies and loves experimenting with subsets of the language, when they're not embracing libraries that let them shift wholly into idioms from some other language. So as fun as it might be to write in some language that had these from the start, I'm not thrilled about giving folks a dozenth way to accomplish the same thing.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: