jeremychone

Sure, there is always some difference in opinions even within the same organization. However, I do not think it is what killed Dart. It would have been a clear winner with clear traction, people will have changed their mind and adopted it (as many did with TypeScript)

I think it was smart of Google of giving it a fair trial and cut its loss when it was time before it got embarrassing or "coffeescript costly" for many developers.

The problem is that all of those new "beautiful" languages is that they trade pragmatism for purity, but at the end, we all have stuff to build, and at the end of the day, a well known, well tested, and good enough language with some modern construct (a la TypeScript and ES2016+) can become a very powerful tool to build small to big code base, whereas a beautiful near perfect languages would have brought us lot of development frictions or little exhilaration.

There is a reason why the Chrome team was not really into it, and they might have been right, but regardless, they should not be blamed for Dart's fall. As developers, I do not think we want another GWT or Google Gear kind of experience.

TypeScript is successful because it solves the right problem the right way, i.e., adding type without changing everything else around it.

Good one. Developers really need to understand Structural vs Nominal typing before saying TypeScript is less type-safe than Java.

Not sure one gives you safer typing than the other in absolute. They both have a different context/purpose. TypeScript is great for typing a code base for function calls type of APIs, whereas GraphQL is great to express types for inter-system communication (usually over HTTP).

Using GraphQL to type your in-process API would be overkilled and would require quite a bit of contortionism, and while you can share same TypeScript types between your end-points interfaces (and can be a good first step), inter-process communication is better expressed with something like GraphQL or Protobuf.

Not sure TypeScript and GraphQL are mutually exclusive.

Not really. TypeScript is just a JavaScript superset, and developer code JS with all its good and bad with some annotation types. TypeScript is not like Dart or reasonML for which your analogy would have been correct if someone said Dart count as JavaScript.

Pretty good resource categorization.

TypeScript is a structural typing model vs nominal one, such as Java, which we are more used to. Not that one is more sound than the other, just different approaches.

I actually like the structural system a lot, and found that combined typescript expressiveness, typing a code base with TS is much more intent driven and requires much less contortionism that a class-for-everything nominal system such as Java. In fact, we ported one of our java backend to node/TS, 40% less code, and as typed if not more. Also, there are simple ways to bring some of the nominal characteristics when needed, but in a language like JS where object literal is a intrasic part of the language, a structural typing system is great fit.

So, yes, their are different approach, but not sure soundness is a good description of those differences.

Now, if TypeScript is used to code JavaScript ”a la” Java, then yes, it could be seen as a loss of functionality.

Wow, this is great. Yes, we need a “tensorflowjs” (with TypeScript types) for Torch, and this seems to be a great start to show the way.

yes, there is a learning curve, but once you have your system in place (for local Kuberenetes Development as well as deployment), then, even of a web-sites, it is a breeze. But yes, still need to be organized.

Thanks, appreciate the answer.

> new coffeescript combined with the verbosity of J2EE

- Saying that TypeScript is like CoffeeScript is almost equivalent than saying that CoffeeScript is like Babel.

- The only part that CoffeeScript and TS (and Babel) have in common is the transpilation step.

- CoffeeScript, Dart, ReasonML, ... are all about creating a pure/clean/elegant languages that use JavaScript as a runtime, and since JavaScript "bytecode" is "sourcecode", they transpile to it.

- TypeScript is all about adding Type annotations to JavaScript without removing or redefining any of the language structure. In fact, the transpilation step is mostly about removing TypeScript more than anything else. Besides enum, as mentioned in one of the comment, TypeScript does not add any language structure beside type related ones (another one is class fields, but coming soon to EcmaScript)

- J2EE (JEE and Spring in some respect) are frameworks, and not languages, and does not really have any comparison with TypeScript. They just encode what they see/saw as best practices/patterns into a set of APIs. TypeScript is a language (or language superset), and can support many different design patterns.

- Perhaps a better statement would have been "verbosity of Java," and while developers can use TypeScript to code JavaScript "Java-style", and bring a lot of the J2EE/Spring/JEE patterns to JavaScript/TypeScript, nothing in TypeScript force or even favor this approach.

- In fact, we use TypeScript to write more robust and maintainable javascript code following a "Functional first, OO/class as needed" style allowing our modules to expose simple and intent-driven APIs. Same signatures as if we were not using TypeScript, but now we know what comes in and what comes out.

- Thanks to TypeScript expressiveness and following our functional first and OO as needed code design, we migrated one of our Java backends to TypeScript/Node, and made the code 40% lighter, better typed, and much simpler and cleaner intent-driven module apis.

Btw, been there as well, where a couple of years ago I mistakingly classified TypeScript in the Dart / CoffeeScript category. I was misguided by the then tight "marketing" coupling with Angular, which I would describe (Angular) as the J2EE for Web UI, and my anti-Microsoft bias for open source project (which I rectified since).

Yes, there is a learning curve, but it is not that high (mostly on setup side), and the value back for any sizable JavaScript code is huge. Even for small projects, once you get the habit of including it, the value is great, especially for 3rd party api discovery.

Also, as a developer will finally drop IE11 support, Babel value will probably diminish, and TypeScript benefits will probably become even more noticed. TypeScript's cost of adoption for babel developers is relatively low since they already have a transpilation step.

(btw, class fields are coming to the JS spec, so this was very babelish of TypeScript to have added this support early on).

I would say definitely yes, good one to learn, and smart bet (and we have avoided lot of hype languages like coffescript, dart, ...).

1. TypeScript is just a modern expressive strutural typing system on top of JavaScript, not a full new language.

2. Modern JavaScript (es2017) is not our old JavaScript, the language matured very well. Not perfect, no language it, but as good as it get for a scripting language, and TypeScript has a lot of structure while keeping its flexiblity.

3. JS/TS really enable a Functional First, OO as needed programming style, which can greatly reduce boilerplate code and API code complexity, which in turn makes the code scale better.

Note: I have been doing Java for the last 20 years, building big enterprise Java app for a living for the last 10 years, and right now, I would say that Modern JS / TypeScript and all of its benefit, offer a better productivity environment for big app development, that traditional Java. We just ported one of our client's Java backend, 40% less code, better typed, and better scale (as most node libs are nio/async in nature)

TypeScript is a structural typing system, vs the normal nominal one we are used to. Now, I agree that even with this difference, still not a strong typing as it could be, however, get pretty close to it (with all of the added expressiveness added to it). So, all in all, for big app dev, Java vs TypeScript, from a typing point of view, it comes pretty close.

One solution would be to have your own service (bound to a public IP) and point a nginx pod doing the routing.

You might be able to use an ingress type nginx, which might be a even better way to handle this. (not sure, because I always use the GCP Load Balancer for my ingress).

CDN, as suggested above, might work, but that has some cost and topology ramifications as well.

Agree about the silliness of some npm modules, however, after 20 years of building enterprise application in Java, I find NodeJS / npm / TypeScript refreshing and a surprisingly robust platform to develop serious backend services.

For example, many libraries are better maintained in the npm/node world than in Java. For example, Node's Google SDK , feels well throughout and maintained, while its java counterpart is cumbersome to use and actually out of date. Java Google Bucket SDK supports all legacy privilege only, whereas the node has to be expected support.

For image processing, finding any well-maintained image processing library in Java is a pain, and at the end, we are back to using something that binds to C++. In node, because the default is binding to C++ for those kinds of things, you have very robust implementation from OpenCV wrapper to sharp binding to libvips.

So, all in all, we have found that we have more chance to find a well maintained high-quality module in npm / node world than in the Maven / Java one. Yes, it was counter-intuitive to us a well, but we have learned the hard way.

Honestly, DI is really a thing of the OO-Obsessed world when everything has to be a class and instantiated.

In the JS/TS world, we mostly use Interface/Type to describe constraints, and most of the module export function or group of methods in a const (namespace, module,...) but the caller does not have to know if it is a class or just a object with some methods, and does not do a "new ..." or @inject... anymore. Much simpler, much more intent driven, and you can remove a lot of boilerplate code (which DI still is)

Now, one of the value of DI is for testing, and one way to accomplish module compartmentalization, is with module-alias. It does not the granularity that DI needs, but I would argue that if more is needed, it perhaps because the testing and mocking got a little too out of hands. In our experience, thanks to Kubernetes, we try to mock less, and have our test running mostly with real services.

I just looked at flow briefly, but for what I can see, TS is a much more advanced typing system, the tool support is amazing (VSCode for example), and most libs today are TypeScript typed one way or another. The later is probably the one as it add for most node libs, intellisense, hover / option-click to drill on the method signatures, and most of the time it will get you to the full lib API description. Productivity is through the roof with those alone.

I would add 1) Starts with `strict: true` 2) Favor interface over class 3) Functional first, OO as needed 4) Avoid Java way of coding, DI, Class for everything.

too bad, does not seem BigInt made it.

I would recommend TypeScript. I was a "pure JS" for years and avoided the GWT, CoffeeScript, and Dart kind of languages. We even avoided Babel as the added value was not there for us).

However, TypeScript is a whole different game, as it is really a superset of JavaScript and let you almost all you can do in JS. The industry support is amazing, most of the major node lib comes with their TypeScript types (from the project itself or from @types/...), and the tooling support in VSCode for example is just amazing.

I looked at Flow a little, and while it seems less intrusive, I am not sure it is as expressive, powerful, and mature as TypeScript typing system.

The trick to realize is that it is not because you have "class", interface, and generics that you have to code JS the Java way. TypeScript does not change your style of writing JS, it just makes it more robust and scalable (with the number of developers & line of code).

yes, we really like conditional typing as well. We do not use it everywhere, but for when it is needed, it is very powerful.

Just one thing that could be better outlined in the TS doc, is that conditional typing is for declaration and not for the signature of the method being implemented. It seems obvious once we know it, but can be confusing at first.

Ok, fair and good points, but I differ.

1) Offensiveness: Yes, this is a open letter to Michael Arrington, and it was blunt and harsh, but I think that his style is the same and more, and his post was a good example on how he can be offensive to a whole community and industry. And my philosophy is that you should treat people the way they treat others.

Btw, I went to the first MA tech events at his house, and he was great then. However, as he got notoriety and became public figure he started lecturing industries over and over, became very aggressive, often disrespectful, and sometime extremely violent. When it was about the blogging and PR industries, I did not have enough context to answer, but as his post targeted my backyard which is the entrepreneur and tech community, I took it to heart to respond an harsh but respectful open letter.

So, yes, it was harsh and blunt and directed at Michael Arrington, but I do not think this post was was rude, disrespectful, or say anything wrong about him.

2) Tech thriving arguments: Ok, apparently we agree on the where, but not the why. My point was that now, since technology has been fully popularized from an interface (e.g, touch) and distribution (e.g. app stores in addition to web), the opportunities are endless. Back in the days, we always had to worry if the user was tech savvy enough to use or install the product, and how to get the product to the users. Over the last few years, this has been virtually illuminated, for consumer and for enterprise users. Touch interface are so natural that virtually anybody can use a computing device nowadays. For me, and the impact that this can have on how further we can absorb computing in our all aspect of our life is just mind blowing. If you add the popularization of 3D printing, which will bring the digital world to the real one, this is even more mind blowing. Anyway, those are really my points, but if you think I missed the bigger picture, let me know, I am genuinely curious.

3) On Michael Arrington giving opinions: I love opinions, I am opinionated, and I also love to be proven wrong, as I learn when I am wrong and don’t when I am right. So, I have nothing about someone giving opinions, I am against people blaming a industry or community about being slow, un-innovative, or unethical, especially when you have a huge voice (which Michael Arrington definitely earned). And this is what Michael Arrington has been doing over and over for the last 5 to 7 years.

We, the older crowd have a responsibility to enable our younger siblings to thrive where we have not, and for this blaming and lecturing ourselves can only be divert people to the wrong direction.

Now, obviously, freedom of speech first and foremost, Michael Arrington had the right to wrote what he wrote, I had the right to disagree with him and his style, and people has the right to disagree with one or the other or both.

Best, thanks for this good points. Curious to hear more about #2.

Thanks for the nice word. To be honest, I heard nothing from Michael Arrington, and I doubt that he would do anything since this article will fade away much faster if he does not.

In a way, being below the radar allows me to do things that could be riskier for other more popular bloggers. There is definitely a fear of Michael Arrington in this industry, still to this day, which is understandable as he has one of biggest microphone and he can be quite unpredictable and violent in his attacks.

The problem, is that removing Michael Arrington from the title make it a totally different title. I did not mean that bored people are boring, it was an answer to Michael Arrington on his "I am bored" post.

Yes, and I am sorry, but nothing I can do.

The last thing I wanted to mean was that bored people were boring, as this new title seem to imply. I find this a little insulting, and definitely wrong.

My point was about Michael Arrington only, and referring to this latest post and his "I am bored because of you guys" insinuation.

So, ironically, by removing the "Michael Arrington" the title has become more "uncivil" and disrespectful IMO. I wish it could be reverted back (I will put a foot note in my article to apologize to HN readers)

Well, the title was the article title "Dear Michael Arrington, Perhaps You Are Bored Because You Are Boring" but somehow it got edited :(

Not sure. What I meant is that what bores me with Mr Arrington, is that he is always lecturing from the passenger sit, rather than just do stuff and show us how things can be done. That's bores me.

Note: The original title for this HN post was "Dear Michael Arrington, Perhaps You Are Bored Because You Are Boring" but somehow got edited to "Perhaps You Are Bored Because You Are Boring."

If someone can tell me why the original HN title was wrong, that would be greatly appreciated.

No big deal, just curious.

First, Michael Arrington has never been a messenger of anybody but himself, so, I did not shoot any messenger.

Second, the real question is can someone interest some and bore other? if yes, in my case, I found Michael Arrington interesting when I went to his very first startup events at his palo alto home, bu then, as he met success (that he rightfully deserved) became to lecture everybody and became very boring to me.

Again, this is my personal opinion that I wanted to share.

@zerooneinfinity

Getting confused, I am not sure who is what anymore.

Also, no need to curse and insult. Just differ without cursing and insulting, much more constructive and less confusing.