Hacker News Reader

Comment by spriggan3 | Hacker News Reader

> We need some more software engineering in the javascript space instead of cowboy hacking

Are you saying that the ability to write entreprise java code is what separates "software engineers" from "cowboy hackers" ? That statement is arrogant.

My point is the use of Typescript doesn't produce idiomatic Javascript code, since it encourages writing front-end code a certain way. You might like it, fine, I'm personally not willing to deal with that kind of over engineering blessed in the Java world, I know what it leads to. If this approach was really successful everybody would be using JWT by now. Obviously they don't.

View on HN

> Are you saying that the ability to write entreprise java code is what separates "software engineers" from "cowboy hackers" ?

I'm saying that software engineering doesn't need to be simple, it needs to be solid. I think type safety is one of those features that makes a language more solid.

Complexity for the sake of it doesn't make software engineering solid. JEE complexity doesn't come from the need to be solid but from Java's flaws. In my book it's the very definition of bad engineering.

Have you used TypeScript? I thought the very same things until I started using it. TS does a great job of maintaining the spirit and feel of JS. It's not a "C# for the web", it really is "JavaScript with types"

It is C# for the web, of which a small subset is great and can be used to make "JavaScript with types".

Or rather, TypeScript isn't bad, but the way it is documented might convince people to do bad things. It took forever to get "the good parts" of JavaScript in people's head, and that doc is really a step backward.

If you just use TypeScript's types and run away with that though, it's pretty good. If you start using classes all over, rely on private/protected/public like crazy to make complicated domain models, abuse decorators to hell, enums, etc... then it's C# for the web.

It doesn't have to be used that way, but those features made available and having a high focus in the official doc is causing a lot of issues when people coming from Java/C# hop in a TypeScript code base.

We don't use TS here, but when we hire people who come from TS companies, we have to tie them down for them not to start writing C#-like code, and remind them that it's structural typing, etc.

I have to disagree. For starters classes came from ES2015. They're an official, first class construct of JavaScript now, whether we like it or not. Decorators are also from ECMAScript. Whether people use TypeScript or not, a lot of what you're complaining about is coming regardless.

The visibility modifiers are optional, only checked at compile time, and quite frankly solve a problem that JS developers have been solving badly for a decade now. From "gentlemen's privates" (ie, if it starts with an underscore please don't touch it or rely on it!), to closures to CommonJS modules, all ridiculous contraptions essentially designed to give you some sense of privacy in the language.

TypeScript doesn't have enums. Instead it allows you to restrict a string to a finite set of values. Which basically boils down to JavaScript "enums" with a dash of static typing thrown in.

I have no doubt TypeScript tends to attract C# and Java developers. But that doesn't take away from the fact that TypeScript is a proper superset of JavaScript, it doesn't force you into a rigid class system at all (structural typing for the win), and really, truly is "JavaScript with types".

Decorators aren't in EcmaScript yet. And the ES standard changed since they were implemented in TS (I honestly don't know if TS changed to accomodate or if they're just mismatched now).

TS sure as hell has something called "enum", which is NOT the same as their string literal types (those are good).

I disagree about the privates: closures are perfectly good functional ways of handling them, and if you didn't want that, we have symbols now to do it for "real". And privates aren't terrible. Protected however are OOP bullshit.

Though my primary point isn't in how its features are implemented: it's how they're advertised. That, to me, is what makes TypeScript "a C# for the web". It's implementation isn't terrible, especially if you stick to the "good parts". However, the "good parts" they advertise/encourages are javascript "bad parts.

Ah you're right, I forgot about the numeric enums. I was thinking strictly string based.

I honestly think "protected" is not worth fussing over. Not to mention JS becomes more classically oriented every day. I predict ES2018 adds "protected" :)

Anyway I honestly don't have much opinion on how they are marketing TS. The language itself is well done and that's all I really care about.

Are you honestly comparing Typescript verbosity with Java type verbosity? It's an absolute joy to work with Typescript in an IDE from JetBrains.

Reply on news.ycombinator.com