Why We Chose Typescript | Hacker News Reader

Why We Chose Typescript

redditblog.com

385 pointsdarwhy385 comments

If you want runtime assertions with flow you can use flow-runtime [0].

Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript.

I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that.

[0] https://codemix.github.io/flow-runtime/#/

[1] https://github.com/babel/babylon/pull/523#issuecomment-31172...

Yep, if anyone can/wants to help out with this effort I would follow/review the issues/PRs in our typescript label https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+lab... (I help with Babel). We'll be working with the TS team to definetely get some better docs on how to setup both Babel and TS once we land the changes in Babel and release 7.0

I was wondering does this make it possible to use proposals which have support in babel but not yet in typescript (e.g. do expression) when writing typescript?

At this point, it make senses for someone to write a TypeScript definition to Flow definition converter. Given how similar the languages are, I feel like you might even get away with using hacky Regex-based transformation instead of using ASTs for a lot of libraries.

I never did understand why Facebook and Microsoft ended up competing on this front.

> I never did understand why Facebook and Microsoft ended up competing on this front.

They ended up competing, but they did not start competing. The projects were started in isolation from each other. The fact that they are written in different languages (Flow: OCaml, TS: TS) makes it hard to merge efforts.

Ah, useful things to know about!

flow-typed does exist, so that's something. https://github.com/flowtype/flow-typed.

Between Flow and Typescript, looks like the latter has all the momentum. But I see one way in which Flow could become relevant again: by becoming 100% compatible with plain JS.

I would love to have type checking, but I'm weary of solutions that aren't really JS, and could fall out of favor or lack good support in the future. I'm pretty sure I'm not the only one.

But Flow type annotations don't really need an incompatible syntax AFAIK; they could just use comments. This way, we wouldn't need to worry about the future of Flow. If the projects dies off or becomes redundant, we're just left with some useful comments - no need to rewrite or transpile our code to native JS.

PS I found an existing project which does this [1], but it requires an additional step and it isn't officially supported. It looks incredibly easy to make Flow work directly with pure JS with comments...

[1] https://github.com/Kegsay/flow-jsdoc

TypeScript can use JSdoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...

Thanks, but from a bit of research it's not clear to me: does this mean that it's possible to use TypeScript to type-check javascript files which include these annotations, without using .ts at all?

Yes, by using --allowJS and --checkJS switches (can also be set in tsconfig.json).

The big thing I liked about Flow over TypeScript was the more accurate type checking. 2.4 looks like it has finally fixed that.

Sorry but what is the use case for Babel + TS? I thought you use either Babel or TS but not both together.

You can use Babel with TS. For example, for JSX you can tell TS to "preserve" the JSX, which means you can tell babel or some other compiler take care of that transformation[1]. You can also use babel with typescript to use the babel presets for stage-[0-4] plugins. You can use the webpack TS loader, awesome-typescript-loader, to work with babel[2].

[1] https://www.typescriptlang.org/docs/handbook/jsx.html [2] https://github.com/s-panferov/awesome-typescript-loader

One case I ran into: using css-loader/style-loader for my css. TS doesn't understand importing css files, so that's where Babel comes in.

In the end i decided to stick to 'old-fashioned' SCSS with an npm script; the downsides of adding Babel to my stack weren't worth the upsides of css modules. Difficult decision to make though.

I guess what I'm saying is that while there is a use case, so far it's been worth it to just stick to TS without Babel, much as I wish it'd be different.

You could use the webpack (which you might be using already) css loader and declare the css file as any.

Babel can now parse TypeScript source and turn it into an AST. It doesn't check types at this point.

Support for DefinitelyTyped is what I really appreciate about Kotlin-to-JS.

What has your experience with kotlin and js been? Kotlin appeals to me a lot more than typescript and seems more practical than reasonml.

No more experience than reading the docs and watching an old talk from Andrey Breslav [1] where he explains how a DSL for HTML generation could work in Kotlin.

I like what I see and look forward to experimenting with it once I have more free-time (currently in grad-school taking summer courses). Kotlin as a language is really compelling, so I've tried to at least stay informed about it.

[1] https://youtu.be/OSBNkqy0UAI

Down-voted because research into language features is useless, I suppose?

TypeScript's IRC channel on Freenode is an amazing, supportive place, too. In sharp contrast to #gonuts, which is a cesspool.

> Using a typed language in our frontend has already paid dividends: our code has fewer type-related bugs, we are more confident making large refactors, and our inline documentation is focused around concepts instead of object shapes and function parameters.

Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible.

> their mistake of using python on the server side

I could not disagree with this sentiment more. As always, reality is more nuanced than this.

There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate.

After all, you don't buy a big mansion out of college because you are going to have a family one day. What is right for you today might not be right for you today.

Companies change as they grow, and switching from move-fast-and-break-things to slow and steady mode is just one of those things alongside all others.

Dynamic languages were great at bringing these companies where they are now: it allowed them to be agile and fast to market with a small team.

Are they going to benefit from switching? Yes, absolutely. But was the original decision a mistake just because the priorities and cost/benefit curves have changed now? I really doubt it.

Having used many languages over the years, the biggest advantage I've seen to dynamically typed languages is that they're easier to learn.

Python and JavaScript are probably the most common "first languages" taught in school. The dynamic typing and lack of complex IDE, compilation, and build system make then easier to learn. Most founders only have a few years of programming experience. Most startups can't afford to hire anyone experienced. Given these constraints, using these languages makes sense.

Dynamic language aren't any faster in practice. You can write quick and dirty spaghetti code in anything. It's only the naive that consider building large, or potentially large, projects in languages without static typing and strong IDE support.

In time I've realized that dynamic typing doesn't give any real advantages. It allows you to reuse variables, something that should never be done. It allows you to put different objects in the same array without having anything in common, which also seems like a bad idea. What else do you get? The language still has types they're just not visible when your writing code. I would much rather have compile-time types so I can use auto complete

Having used many languages over the years, the biggest advantage I've seen to dynamically typed languages is that they're easier to learn.

I love Ruby because of its delightful standard library, its thoughtful syntax which makes manual refactorings easy, not because or in spite of its dynamic types.

I detest Java because of its verbose syntax, its love affair with XML, and because it isn't a good unix citizen. Not because of or in spite of its static type system.

I detest Javascript because of its non-existent standard library, its many, many design errors (slowly being fixed, I know). Not because of its particular type system.

All other things being equal, I would prefer my language of choice to have statically checked, expressive type system. Unfortunately, all other things have not been close to equal historically. Things are improving, and maybe these days it's possible to have your cake and eat it too.

In practice the Python language is so easy that you rarely have bugs related to types. And when you got it, you find it out pretty early.

Types are useful when you grow, but thinking that you can't do anything big and robust without it is ignoring all the people that actually do so.

Another thing is that the simplicity and power of Python leads to having a lot of libs that are actually clean and solid for a lot of stuff. If I need to create anything under 100000 vis/day, I'm 3 times faster than a Go or Java dev on the backend. Literally 3 times.

I also produce better results. With things like Django rest framework, I can get the same REST API, but all the edge cases will be way better handled, small error messages, multi type of auth, etc.

Those things exist because it's fast to code in Python. And yes, dynamic typing help with that a lot.

So yes, it's true I don't have as much code completion and I have to remember a bit more about the code, but it's an exchange I'm making.

When I want to scale up robustness, I use type hints with mypy and get a strong code completion on PyCharm.

3 times faster with zero proof? Java has similar REST frameworks, notably Jersey and Spring Boot. There's also the Play/Dropwizard crowd and Vert.x . Look at spring boot code vs flask, it's almost identical.

Java libraries, particularly those maintained by Google and other tech giants are some of the most solid code ever written. I doubt Python or any other language comes close to the quality of popular Java libraries.

I still don't see how dynamic typing helps with speed? Any Decent IDE will fill in the types for you so you don't even need to key then mostly

Couldn't have written this any better. Also add the need to write shed loads of "test code" in order to reduce the probability of runtime fatal errors that would have been caught by a compiler; and the fact that source code becomes very hard to understand and maintain due to lack of semantic clues from things like types and structure definitions.

Also add the need to write shed loads of "test code" in order to reduce the probability of runtime fatal errors that would have been caught by a compiler

People always say this, and I've never understood it. Can somebody provide an example of a test that you "have" to write in a dynamically typed language that you wouldn't with static typing? If you're referencing nonexistent properties, then any test that hits that line will fail, and such a test should exist regardless of whether you're using static types.

>There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate.

People forget how old reddit is. Most good options in this space for statically compiled languages did not exist back then, so there wasn't really a decision to make. It even predates rails.

and that until 2005 reddit was written in Lisp

And there still is no prove that statically typed languages are somehow more productive or scaleable. It's just taken as an article of faith.

It's hard to "prove" anything in discussions like this. Having been thrown in a few million loc projects, all written rather badly, I found it way easier to figure out what was going on in the ones with static types. At the very least, if you're inheriting an unknown codebase static types are in my experience a 10x speedup when measuring time to actually getting productive.

Dynamic language does not make you more agile, it makes changes more risky and refactoring harder.

However, large part is that for frontend, static languages are just getting there. You need not just language, but also libraries, tutorials, tooling, IDE and so on and so forth.

Typescript nor flow does not absolve you from the need to learn javascript and web in general. If you are working on your first bigger project and still learning good techniques, architecture and concepts, css, having to also learn typescript or flow syntax on top of it off-puts people.

This is partly why I'm so curious about languages like Racket, that let you start with easy, freewheeling dynamic typing, and then move, in parts, to Typed Racket. We just need to convince some big software engineering project to start down that road, so we can collect the data about the approach :-p

TypeScript is not your run of the mill static language.

TypeScript was the first time I ever used a static language without feeling like it was getting in the way or I was losing the power of a dynamic language. So no, they didn't learn their mistake from using Python, they were just coaxed into using an incredible language since, barring masochism, you must compile from something into JavaScript nowadays, and TypeScript is an absolute pleasure.

- Type inference for the laziest. Hands down better than Scala, Swift, or Rust. The only language I've ever used that can infer recursive functions:

    function factorial(n: number) {
      if (n == 0 || n == 1) return 1;
      else n * factorial(n - 1)
    }

- You can define mix-typed maps without a sweat: const defaults = { debug: false, title: 'Banana', width: 100 }

- And as a bonus you can suck the type out for later use:

    type Settings = typeof defaults

- You can mix types without the compiler demanding umpteen incantations.

- Gloriously simple union types.

- Regex types are coming! (e.g. all strings that look like a URL)

- You can type the API of some hidden dynamically-typed insanity if needed.

- You get a REPL for free, and it's pretty easy to debug production code if you haven't mangled all your names.

- Haven't figured how to type something? Want to prototype something quickly? No worries! Your code will still compile.

> You can define mix-typed maps without a sweat: const defaults = { debug: false, title: 'Banana', width: 100 }

That's called a struct (or class) elsewhere.

An instance of mixed-type maps*

Elsewhere one would have to define a struct/class and them create an instance.

This becomes immensely helpful for the incredibly lazy with one off object definitions and wrapper types. If you introduce a class definition alongside an instance, you're now forced to manage two peices of code. The class definition and instance definition. In this case they're coupled which aides maintenance in my experience.

Specifically structural record types, and many statically typed languages don't have them. (not Java, not C++, not Haskell, not Rust, yes Swift, yes OCaml)

What I wanted to point out is that typically a C struct is what you need. The common case is static keys and static value types but dynamic values.

What are interesting use cases for more dynamic (i.e. non-fixed set of keys / types)?

I mean, if you need something super-abstract and flexible, you are unlikely to need a built-in convenient syntax to hardcode such values.

, yes Purescript :)

For those new to this, good search terms are "row polymorphism", "extensible records", and "polymorphic variants".

> infer recursive functions

Any of the mainstream functional languages (which are most likely to have type inference) can infer the types of all functions, unless you use funky language extensions that make type inference undecidable. Rust has a Hindley-Milner system, so it should be able to "infer recursive functions" too (but I can't say for sure since I don't use it).

I've tried in Rust, and it requires a return definition, as do most mainstream functional languages.

Also, mainstream functional languages aren't truly mainstream: I'd struggle to find devs who could help me in consulting gigs.

I'm pretty sure that's just "administrative" and imposed by the syntax (e.g. think Java/C++ function declaration syntax), instead of being something the compiler can't infer. Thanks for clearing this up, though.

    let rec factorial n = 
        if n = 0 || n = 1 then 1 
        else n * factorial (n - 1)

>> The only language I've ever used that can infer recursive functions <<

You don't need to have used other languages to see there's no problem -- just Google -- haskell recursive factorial type inference

Where can I find more info on the upcoming regex types?

Correction: might be coming.* It's a GitHub issue that's received a lot of attention. Apologies, my memory gets optimistically fuzzy when I swoon over a language. ;)

[0]: https://github.com/Microsoft/TypeScript/issues/6579

    Dynamically typed languages for
    large code bases are terrible

The success of Wikipedia, Wordpress, Facebook, Youtube, GitHub etc etc etc and last but not least Reddit seem to prove otherwise.

> seem to prove otherwise

Prove how? They could have succeeded in spite of dynamic typing, not because of it. Facebook defined a new programming language to add static typing to HHVM. The process of plugging into WordPress is infamous in its disorganization.

There’s a lack of good statically-typed languages, so it’s natural for many popular things to be built in dynamically-typed ones, but that doesn’t make the dynamic typing approach better.

I'm going to throw this idea out there: companies can succeed independent of type checking.

> Dynamically typed languages for large code bases are terrible

was the original argument. Success/failure of entire companies has somehow been brought into it.

That's really going out on the limb though...

But you're right. Moreover I noticed obsession with a particular language is often a hallmark of a junior engineer or a recent grad. This this idea of "If you don't use Go/Node.js/etc you'll totally fail".

    Prove how?

By means of natural selection.

    They could have succeeded in spite of
    dynamic typing, not because of it.

You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job?

    Facebook defined a new programming language

No, they wrote a faster runtime.

    to add static typing to HHVM

No, they added type annotations.

    There’s a lack of good statically-typed languages

No, in the past statically typed languages were the norm. C, C++, Java...

It's just that dynamic languages outcompeted them.

> It's just that dynamic languages outcompeted them.

All "trending" languages are statically typed (Rust, Go, Swift, Kotlin, ...) and all the popular JavaScrip-improved-languages are statically typed as well. Even further, many dynamically typed languages have pushed in recent years to add type annotations or even static typing (e.g. mypy).

Dynamic typing is the brainchild of the 90s for rapid initial development. Sustainability has been a big issue from the outset.

Smart answer successful founders of Wikipedia took an existing wiki engine. Their aspirations were not in the software development area.

Highly dynamic languages like Python or PHP or Perl are easy to start with, so they're great for prototypes. Then either a serious rewrite follows, using a statically checked language, or scaffolding is erected to continue to make do with the dynamic code. Microservices help!

If type annotations support a static verifier, they implement static typing (which, after all, is just having a static verifier that uses some combination of annotations and inference to validate types.)

> You think the otherwise smart and successful founders of these projects all made the wrong choice when it came to selecting the right tool for the job?

Not at all! I think dynamic typing hurts code, but there are:

- not always alternatives

- many other slightly suboptimal choices that it’s quite possible to succeed in spite of

> No, they wrote a faster runtime.

I’m referring to Hack, which is in fact another language with static typing. (Type annotations are static typing with compromises, and you can see what’s being gone for.)

> No, in the past statically typed languages were the norm. C, C++, Java...

Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)

> No, they wrote a faster runtime.

Which includes a statically-typed version of PHP, namely Hack, that they use for their code.

> No, they added type annotations.

Hack's type checking is much more sophisticated than mere “annotations”. That label might be better suited to PHP's type system.

>You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job?

Nobody is perfect. Mark Zuckerberg has had his fair share of controversies for example.

>No, in the past statically typed languages were the norm. C, C++, Java...

Not good examples for your argument. These are largely considered poorly statically typed. Compare to ML, Haskell, Ada, Rust, Swift for reference.

"They could have succeeded in spite of dynamic typing, not because of it."

Yes, they could have. Evidence for your hypothesis would be the existence of similarly successful companies that used compiled statically-typed languages from the beginning.

Are there any recent ones?

Are you suggesting that there are no similarly successful companies that used Java, C# or C++?

The same can be said about any company to justify your opinions, like Linkedin, they use Java and Scala and their page speed is so slow. Compared to Facebook they are like a 1900' tractor. A facebook page opens in less than a second, a Linkedin page in 5.

I think it's the fact LinkedIn uses Ember. Anything built with Ember is sluggish and bloated

>Prove how? They could have succeeded in spite of dynamic typing, not because of it.

Then maybe the burden of proof is on you?

If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way.

And until you have gone back and forth a couple of times, building moderately complex systems; it's difficult to appreciate the advantages that static checking bring to the table. Sure, it's possible to achieve the same effect with unit tests; but having half of those tests written and rewritten for you by the compiler definitely helps. Back in the days, I wanted to buy into the Python/Ruby hype as much as anyone; but having implemented several complex systems in Python/Ruby, I'm not that excited about the idea anymore; once they pass a certain point, agile begins to feel more like Jello.

> Then maybe the burden of proof is on you?

I’m saying that the parent doesn’t prove its point, and I’m not attempting to prove its parent’s point.

> If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way.

I didn’t, and the bulk of what I’ve built has been in languages with dynamic typing. See https://news.ycombinator.com/item?id=14675577. Dismissing stuff as “recent starts” is pretty cheap, anyway.

Most of these languages are pretty terrible to run at scale.

Also, all of the examples you cite a rather the "in spite of" kind. Wikipedia? Struggles to maintain the code base, lest to speak of significant new development. Wordpress? Afterwit of web security. Facebook? Facebook literally developed a new PHP implementation (edit: actually, two) and then turned that into a separate language (which is statically typed) because that's easier than to clean up their PHP code base. YouTube? Maybe some help pages are still on Python. The application most likely isn't at all. GitHub? Goes down every few days with 500s after buggy code was deployed.

The majority of YouTube is in Python 2.7 and actually served as the impetus for GrumPy [1], a transpiler to convert Python to Go.

[1] https://github.com/google/grumpy/

They all started with dynamically typed languages because that was what the founders knew best when they started working on their project. Yes, you can build successful projects with dynamically typed languages but it is a pain to refactor when you grow. You even introduce a class of bugs doesn’t exist for statically typed languages. You don’t see them redo everything only because the cost would be to big. Some developed their custom tooling to handle the language they are stuck with, see Facebook.

> You even introduce a class of bugs doesn’t exist for statically typed languages.

Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.

I've had professional jobs writing both Python and Haskell. My Python code has to be far more verbose and complex than my Haskell, and the Python's harder to maintain too!

> Type bugs just aren't that painful.

You haven't learned the true power of a decent type system then.

> you're also able to write equivalent functionality with less code

The amount of code one writes says more about the language than whether or not it's statically typed.

To me, adding "bigint" or "bool" to the occasional variable and function declaration isn't "more code", it's an extremely terse way of avoiding different code (e.g. type assertions).

The biggest advantage of dynamically typed languages is the ease of using deeply nested data structures with mixed data types. This is just a pain in languages like Java and Scala where the Any type is often reverted to.

A rudimentary end2end test should catch most type related bugs. A type system aids in refactoring, not so much actually catching bugs.

Type systems can enforce so much more, depending on the language. They make reasoning about the code far easier for both human and machine. They enable efficient optimization. They allow far superior static analysis. They allow superior IDE assistance. They improve code navigability (ag/grep). There are countless advantages to static typing, and most of the disadvantages simply don't exist in modern languages any more. Meanwhile, dynamic languages haven't evolved significantly, except to add type annotations, which are like types, just almost always less powerful and not enforced by default.

Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth.

That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.

Static types are better and cheaper at catching type related bugs than a myriad of end-to-end tests that check dynamic types.

> You even introduce a class of bugs doesn’t exist for statically typed languages.

As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true.

What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.

That's not proof though. You can have a successful website with a terrible code base and vice versa.

The quality of your code base largely affects the ability to roll out new features with limited regressions.

I bet a lot of their business logic is written in Java or C++. As far as I know Facebook has a lot of C++ and Youtube's video handling is probably also not written in Javascript.

Even pigs fly, given enough thrust.

I am a HUGE coffeescript fan. What I liked about flow was seemingly unobtrusive typing/type hinting. I am not a fan of type-strict languages because I spend more time thinking about types and contracts around them than milestones/design goals.

Anyway, to each their own. I want "Unobtrusive Typing" to be a thing.

Plain Javascript is valid typescript. You can add types where you need them, via type declarations or jsdoc comments. Typescript is easy to use in a partial way, the type system only gets complicated if you turn on all the strictness settings and have to explicitly annotate every type, even in dynamic code.

Eevee's Law: Facebook and Wikipedia could have been written in Brainfuck, as long as they can find enough smart people to mangle it. The fact that a major site is written in a language doesn't say anything about the quality of the language.

You are mixing the financial and technical successes...

Look at the mess of wordpress code. It's an abomaly and security history proves how it was never a technical success.

Can you source some of these? Genuinely curious.

You mean sources for languages used in the implementation of various websites?

- Wikipedia is mostly PHP https://github.com/wikimedia/mediawiki

- Wordpress is PHP https://github.com/WordPress/WordPress

- Facebook started in PHP https://www.quora.com/What-programming-languages-are-used-at...

- YouTube started in Python https://www.quora.com/Is-YouTube-still-written-in-Python

- GitHub is Ruby https://github.com/showcases/projects-that-power-github

- Reddit is mostly Python https://www.reddit.com/wiki/faq#wiki_what_is_reddit_written_...

GitHub is _mostly_ Ruby -- there's Go, Python, C, and I think some Haskell in production on the website (there used to be some Erlang in there too, but iirc that's gone now). The Visual Studio and Unity extensions are written in C#. The new GitHub Desktop is written entirely in Typescript.

Yes, exactly. Thanks very much. Do you know if Facebook/ Youtube are still in PHP / Python?

instagram, dropbox, etc

It might say something that the creator of Python is working at Dropbox and currently on a project to add static typing to it…

(https://github.com/python/mypy/commits/master because I know the pain of linkless comments)

I never understood why people fetishize writing monolithic applications myself. In practice, any large application can be broken down into isolated components that you can reason about independently. It seems like people often use a static typing as a crutch instead of spending the time to design their applications properly, and break them up into small reusable components that are easy to maintain.

My team has been working with Clojure for the past 6 years, and we've built and maintain a number of large applications. Dynamic typing is absolutely not a problem for us.

I find that immutability plays a far bigger role when it comes to maintaining large applications. When you work with immutable data, it becomes possible to safely reason about parts of the application in isolation. This is a key factor in making large apps maintainable.

This is only possible if you can precisely draw business domain boundaries. Micro-services add large operational overhead. If you slice you application in wrong way you will suffer...

IMO it is better to start from monolith and then extract services.

There aren't any micro-services in our applications. However, drawing business boundaries is much easier to do in Clojure than most languages I've used.

You have a common set of data structures that all functions operate on. To create a piece of domain logic, I simply need to create a namespace, and put the related functions there.

This style of code is highly composable. Since majority of functions are doing generic transformations, the domain specific logic is expressed by chaining these functions in a particular way to get a desired transformation. When I need a different kind of transformation, then I just chain the functions in a different order. My experience is that the business logic naturally bubbles up to a thin layer at the top.

Mistakes? A dynamic language with fast protyping and a vibrant community helped them build a successful business. Sounds like a lesson of success to me.

Had they started building it in C++ or Haskell they might still be building it with 0 customers onboard while some other company which used Python would be dominating the market.

https://danluu.com/empirical-pl/

"Dynamically typed languages for large code bases are terrible."

Perhaps this is what you believe based on your experience or opinions on internet.

However large code bases, complex systems, have been used successfully, for example for:

- Driving the Deep Space 1 (DS1) NASA spacecraft for 3 days without manual input.

- Search for airline ticket reservations encompassing almost all the airports in the world and most airline companies, not to mention all the diverse routes available. Really complex stuff. (ITA software, currently in use across the globe)

These big, complex applications were written in a dynamically typed language.

You should perhaps mention that your examples are also written in a Lisp dialect which is a rather different thing from your average 90s script language.

The most important metric for Startups is time to market, developer productivity, fast iteration times and developer ecosystem which is why most startups (and many of the most popular websites) still use dynamic languages today.

Once their core feature-set is established and they've developed the product they want they can go back and optimize accordingly and rewrite parts of their code-base to use the most appropriate language, e.g. rewriting hot spots in C/C++/Rust/Go, highly concurrent features in Erlang/Go, etc. If code-maintenance becomes problematic they can explore annotating their code-base with Types, adopt linters or even rewrite into a statically-typed language. None of this is a mistake, languages/technologies are a tool to achieve your business objectives, if adopting a dynamic language lets you get an MVP quicker and add/change features based on Customer feedback quicker, then that's likely the best choice.

End users don't care what language servers are written in and it's definitely not a mistake to start with a dynamic language, even today.

Of course if you feel most productive with a statically-typed language that's a fine option as well which may result in less technical debt/rewrites later at the cost of initial velocity upfront.

I believe that we tend to get causality wrong on this one. I don't think dynamic languages have some intrinsic property that makes us more productive or facilitate faster time to market.

Rather, I believe that people who are concerned about the soundness, consistency and maintainability of their code, and hence favor powerful static type systems, are incapable of prioritising time to market.

Statically typed languages increase productivity by catching errors early, but decrease productivity by making users jump through hoops.

e.g. at one end of the spectrum is Java, which everything has to be a class. Even if you want to write a function, it has to be expressed as a static method in a class. In Java it's just not possible to implement ideas in the most obvious way, it has to be done in the Java way.

Conversely, TypeScript was designed to work with JavaScript (which is very dynamic), so it has a very capable structural type system. The productivity penalty is negligible.

What I love about TS is that it's up to me how much effort I want to put into the type system. I find that I end up using TS even for very small projects, because I can use it for only 'the important' bits.

That said, my background is mostly Ruby/Python/JS/PHP, so for all I know this is true of many statically typed languages (but from what I read this is not the case).

Still, for those with a background similar to mine I can highly recommend TS as a great starting point for more statically-typed code, precisely because it's opt-in if you want it to be.

End users absolutely care when the program or service is slow, unstable, drains your battery, is constantly offline, or has major security flaws.

Now there is no guarantee that a dynamic language will have those issues more than a static language, but I for one sleep better at night knowing my compiler is doing so much more work for me.

> End users absolutely care when the program or service is slow

A Ruby API with a good caching strategy is faster than a C/C++ binary with none and it's much easier to implement sophisticated caching strategies in dynamic languages.

> unstable, drains your battery, is constantly offline

Servers don't drain battery. Unstable, constantly offline has no correlation and is not limited to dynamic languages

> but I for one sleep better at night knowing my compiler is doing so much more work for me.

Right, choose whatever helps you sleep at night, but your language/tech choices isn't always what helps everyone else sleep.

A static language is less likely to throw a runtime type error, or coerce some value incorrectly, than a dynamic language. That does correlate with being unstable and offline.

Servers don't drain battery, but they cost money, so inefficiency matters server-side as well.

And comparing a fully-featured dynamic language implementation with a less-featured implementation in a fairly weak statically typed language isn't really a productive comparison, is it.

Actually I really wish there was an option similar to typescript for Python. There are promising things.. but the annotations, for example, are just not there yet

I'm very satisfied with the new typing [0][1] module. It's part of the standard library since Python 3.5 and it provides type annotations similar to those of Typescript. It's still missing some features (IMO), but it's also under active development, so I guess more useful features will come.

  from typing import List

  Vector = List[float]

  def scale(scalar: float, vector: Vector) -> Vector:
      return [scalar * num for num in vector]

  def greeting(name: str) -> str:
      return 'Hello ' + name

[0] https://github.com/python/typing [1] https://docs.python.org/3/library/typing.html

what would you say are the limitations of Python type annotations? From the pycon demos I've seen it seems pretty functional and complete.

* pylint / pep8 doesn't parse comment-based annotations, and thus flags imports that are in use as "unused"

* numbers.Real / Union[float,int] do not work correctly; I basically can't figure a way to annotate a function that takes an int/float/decimal/etc.

(mypy doesn't think "int" is a valid "Real", and it doesn't think you can add two Union[float,int] objects.)

(mypy has nonetheless been very helpful, and overall I would recommend it.)

> I basically can't figure a way to annotate a function that takes an int/float/decimal/etc.

It seems like you should be able to just annotate it with float?

... when an argument is annotated as having type float , an argument of type int is acceptable ...

https://www.python.org/dev/peps/pep-0484/#the-numeric-tower

You don't need comment based annotations since there are real annotations since python 3.5

I mostly found the type annotations to be sufficient, though the tooling look leaves something to be desired.

Annotations at least help the IDE dig through the mess faster. That's ... something. I guess.

>Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible.

Yeah, those pesky dynamic languages only power some of the biggest sites on earth...

its not always about the size of the site, but the size of the code base, the amount of the services and most of all, the amount of engineers working on it.

Is Typescript necessary for front-end Javascript?

In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Textbook logic as why to use strong types make absolute sense. Yet in the real world, I've had to fight with logic, DOM, UX, framework incomprehension and other types of bugs - not types. Type issues were anomalies among bugs. When they came up, they were the easiest to fix.

Am I alone here? Anyone in the community have concrete examples of type-related bugs that took so much time to required using something like Typescript? Can anyone quantify that?

> In the many years I've done front-end with Javascript, type-related bugs were very, very rare.

Wow, really? My experience has been the complete opposite.

Most of the bugs that slip into production have been dumb type errors. Things like accessing a property on an null/undefined value, or on an object that doesn't have that property and unfortunately JS just returns `undefined` instead of complaining (these silent ones can live longer before being spotted).

It's because of these kind of bugs that i've found many JS codebases tend to become brittle to the slightest change, and very difficult to refactor into a good shape. And why i'm seeking statically typed languages like TypeScript on that front at the moment.

But that's really a symptom of a "big ball of mud" design (non-design, really), where everything has dependencies scattered all over the system, and to change anything you have to consider everything.

Type checking can help you with a few kinds of problems you'll have trying to make changes in those kinds of systems, but you still have piles of problems and it doesn't do anything to help improve the underlying issue.

Static types can help you with some small problems, but that doesn't mean much when the problems you have are big.

> But that's really a symptom of a "big ball of mud" design (non-design, really)

Yep, that's exactly the problem :)

The thing is that, without ease of refactoring, it's very difficult to change that big ball of mud into something prettier. In fact, i'd say that without ease of refactoring it's kind of inevitable to fall into that big ball of mud "design" in the long run.

(Note: static type systems are not the only tools to help with refactoring. Good test coverage, style guidelines, a well documented / simple architecture, are of course very helpful too.)

Exactly. Static types ( I've used flow not typescript, but similar ) and good unit tests allow ridiculously easy and merciless refactoring of enormous swaths of code in an extremely short period of time with incredibly high confidence.

Integration tests ( not to be confused with functional tests / i.e.: selenium ) that test multiple classes in concert via input / expected output give the most bang for the buck, because you know your code works as a whole.

Static types are especially useful in big ball of mud design because you can refactor it (like change the shape of a canonical object) and mechanically fix all write/read sites without running the code.

Not sure how that's a small problem unless you never refactor code.

It's more likely that OP finds such errors just as frequently but because they are relatively straightforward to fix he doesn't weigh them as much as edge case debugging.

I've heard this same argument from a coworker working on a different project recently working on React/ES6 stack - I check their TFS history and find 3 such fixes in last 2 weeks (and they have reviews before checking in to TFS).

There's a lot of type bugs in my code as I type it, and while I'm writing the unit tests, but I've been keeping track for the last year or so when they happen in QA or Prod and they are quite rare for us (as part of an evaluation of if we should move to Flow/TS).

But there was a heavy correlation between type bugs and the kind of code being written. Our transactional frontend apps? Most bugs are browser css issues, weird environment specific edge cases, misunderstandings of the backend, memory leaks, etc.

In apps that are data heavy though, or backend JS apps, its a whole other story. Type bugs all day every day (though a part of it is because we don't do many and they aren't high profile here, they're very light on tests).

So we moved the later to using tests. While it helps a lot, we did end up with a different kind of issues: broken type definition issues and bugs in the type system. Turns out a very large portion of DefinitelyTyped definitions (especially those of the more obscure libs) are broken and you can't trust them, but you lose a lot of time fixing runtime bugs the type system forced you to make. And while they never hit production, there's more bugs than expected in TS itself, and it takes a while to figure out if I'm doing something wrong before I go look at the bug tracker (the issues I hit have almost always been reported already, but I don't expect them). Fortunately that last category rarely cause issues in production.

> while I'm writing the unit tests

With types you can test quite less. You still should but test code is the worst code, it turns legacy so quickly.

Isn't refactoring TS also unpredictable? since its type system its no sound.

The short answer is: it depends. With TS you can choose how much type "soundness" you want. The --strict option is very useful[1], but even having it enabled you can still choose to explicitly type something as `any`, and bypass the typechecker if you want.

Something to note though: the example given in the article is not showing any problem in TS. That's how its structural type system works. Both Animal and Bird classes don't have any properties, so the type of their instances is the same as `{}`. If you change the Bird class to something like:

  class Bird extends Animal {
    song: string
  }

Then the line that tries to push a `new Animal` into an Array<Bird> will not type-check, because the types are invalid :)

[1]: https://www.typescriptlang.org/docs/handbook/compiler-option...

Unfortunately I feel that this type of example expresses what not to do with type systems -- favoring composition over inheritance goes a long way to not finding yourself in a brittle type hierarchy and especially in a JavaScript environment where composition is so easily used (and with typescript, still type checked)

One solution to the any typing problem is to use tslint with no-any. It's a bandaid, but it's better than nothing.

Type errors might not be the biggest issue up-front when writing new frontend code, but refactoring JS becomes really hard as the LOCs grow. Typescript (static typeing in general) really helps with this as you can get instance feedback about how you're changing interfaces between parts of the system.

Another reason i've enjoyed TS is the editor intellisense support. It's really helpful when using a library to get type info in your editor instead of having to google when you forget what a function returns, for example. This is also helpful when you're coming back to code you wrote a long time ago, or a colleague wrote it, and you don't know what particular variables/function arguments/object properties are at a given spot in the code.

Oh yeah, that's another great point (although you're still stuck with the fact that somebody can access object properties by key).

Couldn't you solve this with privates, either via a naming convention or with symbols, as well as using getters?

Not really. If I declare that an object has property xyz obj.xyz and obj['xyz'] are both valid ways of addressing it.

Absolutely. Typing is a real timesaver as it adds so much to how much an ide can help you.

Like others, my experience was also complete opposite.

The app I did was a financial related app so we do some good amount of number crunching. From calculations, to transfers, and storage.

You won't believe how many type errors we had throughout the stack. It's definitely because of JavaScript's inability to do type checking.

One workaround people did was to do the type checking in the first few lines of the function call, which is how people that still do raw JavaScript, do it today.

    function add(a,b) {
      if (typeof a !== 'number') { ... }
      if (typeof b !== 'number') { ... }

      return a + b;
    }

This eventually creeps throughout in the code and introduces this code smell.

This above can be solved by just using TypeScript.

For me it is not about catching bugs that would make it into production; I agree those are relatively rare. It is about catching simple mistakes while I'm in the middle of coding or refactoring. These are mistakes that even without the warnings would probably not even make it into a commit, but the warnings directly in my editor in real-time are an even shorter round-trip than test executions. It results in less fumbling around to find the actual cause of some failure.

I have seen quite a few of those - mostly in returning promise vs actual value from function in some special case.

The other class of errors was with objects that reference other objects - e.g. function takes `loggedUser` parameter which is expected to have property `finishedLevels` or some such and someone sends it `bestFriend` object that kinda looks similar but does not have 'finishedLevels` property.

Most importantly, you have to code differently when writing without typing. It felt as if my hands were cut of at first - I was often in "I would solve this easily in Java just by making interface that would communicate list of needed methods, but cant in javascript because there is no such thing as interface". This is also the likely reason why you do not see many bugs - you probably learned to avoid all those patterns and idioms.

Even more importantly, it really helps with refactoring if you can rename function/variable or change number of its parameters and have all the places (and exactly them) that call that place return error. I can refactor much more aggressively when working with java vs javascript. In java, I spend a lot of time changing existing stuff, when I am tired to do hard work. In javascript it is special thing you do when you are well rested and fully focused.

One major argument is that TypeScript gives you arity checking on function calls, especially as you're refactoring. Seems like a simple thing, but after using TypeScript I realized how much time I wasted solving things like that.

> Am I alone here?

I am not a Javascript person, but my personal experience has been similar.

FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.

Lately I have warmed up to statically typed languages, but among all the bugs I have run across in dynamically typed languages, unexpected/invalid/wrong types were very, very rare.

The benefit of good type system - IMHO - is not that it keeps you from putting string where a number is required. That kind of problem happens, but is usually easy to fix. But a type system that helps you distinguish between, e.g., numbers that are temperatures and numbers that are air pressure measurements is worth having around.

EDIT: I admit, C's type system is exactly the most sophisticated one I've seen.

> FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.

How is that a non-issue? If you don't have unit tests covering your entire code base you wouldn't notice a bug like that until it broke in production.

Having type checks let's you catch obviously wrong things like accessing a Promise return value directly rather than interacting with it as a Promise (i.e. then or async/await).

> How is that a non-issue?

In C, there is a distinction between a value and a pointer to some value. In Javascript, as far as I understand, everything is a reference, so the specific mistake the C compiler caught would be impossible to make in Javascript in the first place. (Then again, C does not have concept of promises.)

I am not saying type checks are bad or useless. In fact, over the years, I have grown to appreciate every little bit of advice a static analyzer can give me. But among the bugs I have produced using dynamically typed languages, few had to do with using the wrong type.

> C's type system is exactly the most sophisticated one I've seen.

Oh-oh, too late to edit.

Of course, what I meant to say was: C's type system is NOT exactly the most sophisticated one I've seen. ;-) I like C a lot, but type safety was not its top priority.

Is it "necessary"? Of course not. Lots of people have done without. I do find that it makes it more productive and easier to debug, especially if you're making something like a SPA with complex functionality.

Also, the point isn't so much that there is one major, hard-to-fix bug, but that there are lots of small ones that you never encounter.

I agree. Type-related bugs of the kind that TS can catch are indeed rare and trivial. However, TS does help with documentation, intellisense and refactoring. Personally, I will usually go with Babel/JS, since I don't find that the benefits of static typing outweigh the costs.

I find the costs of static typing very low. What costs do you have in mind?

Everything required to add that to regular Javascript: transpilation, extra markup and understanding and mastering a new tool. Another layer to manage and debug if you will.

Assuming you use ES6+ in production, so you need a build step anyways, would you still say TS adds costs that aren't worth it to you? And if so, which costs? I mean that in full honesty, as I generally find myself conflicted whenever I start a new project: TS or ES2015+?

Oh. But these days most JS projects are in some task runner anyway.

> Javascript, type-related bugs were very, very rare.

That's because you're not seeing them. I bet that if you plug your frontend to an error-reporting tool (e.g. Sentry) you will be overwhelmed to see all the corner-cases you are overseeing.

but how much of these edge cases are really happening?

Sentry and tools like it are reporting errors that are happening in production to real users.

Ah okay, so it's not reporting theoretical edge cases but real errors?

Javascript without type info is nearly impossible to refactor effectively.

Catching wrong-type bugs is, for me, relatively low on the list of reasons I enjoy using Typescript. A few of my higher items would be: strictNullChecking, intellisense, and refactoring.

Agree the academia-touted benefit of type-checking isn't that helpful in practice. But types help with documentation and tooling (completion, data-mapping etc).

Types are (apparently) crucial for large projects. However, the #1 benefit is speed, which I don't think Typescript can provide.

Sorry I can't quantify any of that.

EDIT I am curious why this was downvoted.

The number one benefit is that it makes it painful to write certain classes of error prone and hard to read code.

It's hard to take these kind of posts seriously when Reddit mobile site is one of the worst performing SPAs I've ever used.

The reddit mobile page is a (bad) joke and the app is far inferior to 3rd party offerings (personally I use Sync).

+1 Sync Pro

What are your specific criticisms?

After I wait eight seconds for the page to load, I see your lovely reminder that I should "View Reddit in the app because I deserve the best." At the very least, you could have the decency to harass me about your app while I'm already waiting.

Also, I can load the desktop version of the site in under a second on my phone. IMO y'all should've stuck with some good old fashion HTML and CSS, especially since there's nothing dynamic about Reddit's content.

Hell, you guys could probably get away with responsive styles alone, but I get it. As a business, you find it optimal to piss off your users into downloading an app so you can send them push notifications, dig into their contacts, and find out where they're eating tacos.

> IMO y'all should've stuck with some good old fashion HTML and CSS, especially since there's nothing dynamic about Reddit's content.

Agreed.

I use mobile tethering as my home internet. Currently reddit loads in under 1 second per page usually. The new JS-heavy profile page usually takes 5 seconds or more to load (assuming I'm willing to enable JS to see whatever crap is on one when I bump into them -- usually I'm not...) Note that that's with full bandwidth. When I hit my data cap, I'm throttled to 8KB/s... The current design of reddit is one of the few sites that I can actually reliably load quickly under those conditions! They should seriously think twice about throwing away something that works that well.

Personally, I find the entire experience to be incredibly slow. Loading the front page takes multiple seconds, there is a noticeable delay between tapping a link and any form of response, and back navigations are often unexpectedly slow.

Non-SPA related, I also think that many of the touch targets are too small, or work in unexpected ways. Tapping a username collapses a comment, even though there's an arrow next to it. Tapping an image associated with a link doesn't follow the link, it expands the image (even if it is an article link). Tapping the title takes you to the comments, not the article. The only way to get to the content is to click the itty bitty domain title beneath the title. All of these behaviors are different than how the desktop view behaves. For a site that calls itself the front page of the internet, it's getting harder and harder to get to actual content.

Install the app! It solves these usability problems. No? ... waits 5 seconds... HEY INSTALL THE APP. HEY, HAVE YOU HEARD OF THE APP?

That's funny. Reddit took over my [desktop] web surfing precisely because of how much faster/cleaner it is than any other comparable website. Beaten only by HN.

HN is usability and speed taken to the extreme. I mean it the personification of Unix philosophy 'do one thing and do it right'. So no bloats.

I am going add my experiences here, in hopes someone from Reddit sees them, but they are more or less the same as everyone else's criticisms.

The reddit mobile site takes 13 seconds to load on my Nexus 6 over wifi. Then it has the nagware ad to try to get me to install the app, which only has a tiny 'go to mobile site' link directly underneath the large 'continue [to download]' button. Once reddit has finally loaded, every link will then first ask you if you want to view the link the app, before allowing you to continue. Meanwhile the UI, while cleaner, is debatably worse off UX wise as everything is now small and laggy.

So to summarize, it is terribly unperformant app, filled with dark patterns and dubious UI improvements.

On Chrome on iOS on iPhone 6, posts take too long to load, and having more than 3 gifs expanded at once crashes my browser. Also manual pagination instead of infinite scroll is a little annoying.

Works very well otherwise.

I've worked with TypeScript on and off for a couple of years now. I don't like it.

The compilation step is a major pain. Even after using it for several months straight, I feel like I'm in a constant battle with the compiler. It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time); you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.

I have gone back and forth from dynamically typed languages to statically typed languages many times for years and I've spoken with engineers who used to be Java developers for many years, then switched to Javascript, then TypeScript and they shared the same thoughts as I did. TypeScript is slow and restrictive in a way that is unnecessary. It's got Microsoft all over it.

Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.

At my previous work, even developers who said that they liked TypeScript secretly didn't like it because they used the 'any' type Everywhere.

I wonder if the people who are making this decision have actually tried TypeScript themselves for any decent amount of time on a decent sized project. I don't think they know what they're getting into.

I decided not to renew a lucrative contract at a finance firm as a front-end developer in part because I did not enjoy using TypeScript every day.

> It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time);

Have you ever used `tsc --watch`? First build can take long but modification and rebuild takes < 1s.

> you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.

You don't "have to" use the debugger if you prefer `console.log` all the way. However in the debugger there is a "watch" tab for inspecting specific variables.

> Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.

VSCode? https://code.visualstudio.com/

Using console.log is not practical with TS because I only get one chance per debug cycle to log the value of the variable which I think is of interest. If that doesn't give me any insight, I have to log another variable. This is fine with JavaScript because it takes me about 2 seconds to add a console.log and check it. With TypeScript, the cycle takes about 10 to 15 seconds, so it's not efficient to do that, so yes, I end up having to fiddle with the debugger, add watchers and hover over individual variables... I kind of have to deal with the debugger's clunky UI every time which is slower. If source maps don't work correctly (as was the case for a lot of projects), then the debugger is even more of a pain.

I've worked on TS on large existing projects as part of large teams. In my last project, we did have some sort of file system watcher but it still took > 10 seconds on average to compile. Launching the project from scratch took longer than 1 minute. From time to time, I did have to relaunch the whole app; usually for a different reason every time.

I have been working now for 2 years with Typescript on a heavy SPA in combination with ASP.Net / AngularJS 1.5 components, and absolutely love it. I have zero compiler issues. We started with plain javascript but switched to Typescript later on, and it still amazes me how many small mistakes we made that have been preventing by just adding typing. Automatic Refactoring and Find Usages alone are worth 10x the small delay in compilation.

The biggest gripe I have is that Chrome debugging is hell, because sometimes it will recognized the typescript, sometimes only the javascript. I have hit Ctrl-P many times to "establish" mappings between files running in IIS Express and local files. Miss and hit.

I use console.log all the time so I don't understand your comment in that regard. It works perfectly fine with Typescript.

Ah yes I had forgotten about the source map issues. My point is there is almost always something wrong with it depending on the project. The source maps issues are pretty serious.

Not having the same code on paper and on machine so to speak does make debugging typescript a little hard. It's a little bit of a black-box.

I code typescript for Angular 2/4, and although yeah, the aforementioned debugging pains are annoying, the time saved on having types to enable linting and strong predictable variable comparisons, is much greater.

Also, needing console.logs everywhere should be discouraged. Your code should be clear enough that you don't need a console.log debug line to print the boolean result of a comparison, for example. This is the whole point of typescript like I said, to make variable comparision and management easier so that you don't need that console.log line...

I don't mean leaving console.log everywhere, just when debugging, when you want to check the value of a specific variable quickly without having to click around in the debugger.

Developers from statically typed backgrounds just don't seem to understand this use case. It's the quickest way to find an issue when you have a good idea of where the problem might be.

This is the first negative comment I've ever heard about TypeScript, which makes it really interesting. I thought it was all praise.

You don't need years of trials. One thing that people forget is that types are a parallel ecosystem more times than not i.e. DefinitelyTyped. So you do not have that lock-step that is praised. So imagine wanting to use a brand new webextension api - stop, add it to types. Want to upgrade a dependency - stop, the types are not working/incorrect/incomplete e.g. https://github.com/DefinitelyTyped/DefinitelyTyped/issues/17...

AFAICS the Typescript types ecosystem is bigger simply because Typescript has been advertised to devs coming from a background of a statically typed lang, and they cannot imagine not using types, thus they drown in them.

Flow on the other hand appeals to those that want types primarily in their own codebase, and come from inferred/dynamically typed langs, where you gradually add static types starting with key sensitive parts in your codebase e.g. Erlang http://learnyousomeerlang.com/types-or-lack-thereof

What about using the TypeScript toolchain as a JavaScript static analyis tool without actually writing in TypeScript? (tsc can still verify your js files are minimally 'correct' through type-inference, for example).

I'm coming at this from the Elm-camp, and my first impression (and largely why I think languages like Elm is promising) is how languages that are implemented as supersets of other languages have the potential to be as bad as their subsets.

The example that I was given was C++ and C, but I think TypeScript with it's gradual-typing approach is forced to remain potentially as bad as JavaScript itself - that is, if you're feeling weak and want to "get shit done", you can bypass all the goodness that TypeScript undeniably offers you.

For a language like Elm, the type-system is invariably gonna have your back - a value-proposition I think means a lot more in practice than some self-proclaimed pragmatists realize :)

I absolutely love Elm, and think it's great because it's a totally new approach for the frontend. That said, new approaches take much longer to build the critical mass for adoption than incremental ones (like Typescript). In a lot of ways, Elm reminds me of this Onion article from the early 2000's.

"Ghost Of Christmas Future Taunts Children With Visions Of PlayStation 5"

http://www.theonion.com/article/ghost-of-christmas-future-ta...

There's a project on my plate right now that when I saw the requirements and specs, I immediately thought, wow, Elm in a year from now would be absolutely perfect for this.

But it's just not there yet, so I'm exploring things like Typescript that have the advantage of the Javascript ecosystem beneath it. But I really cannot wait for Elm to be production-ready across the board and not just for specific use cases.

Check out Purescript [0]. I've used it in production.

[0] http://www.purescript.org

tsc --noImplicitAny solves that.

Or to go all-in - we have a `--strict` flag that gives you `noImplicitAny`, `strictNullChecks`, `noImplicitThis`, and a mode that always puts you in `"use strict"` mode.

I don't understand why `strictNullChecks` is not the default behavior. It being a special compiler option makes me somewhat dubious of TypeScript in general.

I think when he says bypass, he might mean you can explicitly cast to `any`.

Wondering why Dart was not considered. Large apps are written in it (Ad sense UI, Ad Words UI, Google CRM). Has good tooling (IntelliJ plugin, Webstorm). It's fairly easy to pick up - Java/C# like syntax. It's harder to shot yourself on your own foot (it's not JS superset). It has strong mode. It has superb tooling and package manager ( dartanalyzer, pub)

Dart is for Google, by Google, and external engagement has been as neglected as for all of Google's front end efforts. Google ceded the thought leader position in this area years ago and everybody knows better than to trust any of their new efforts.

There's still polymer which is developed by chrome team and angular2 by ads department and those seem to be quite industry proven. E.g. angular2 is one of the main adopter of typescript.

Don't forget that Google's first instinct for Angular 2 was to create an incompatible fork of TypeScript.

https://en.wikipedia.org/wiki/AtScript

So this is official reason why it was not considered ?

I don't know, but the reddit blog post says:

> One of the worries we had with Flow was that it was built to solve specific needs at Facebook and that its future would be determined by that scope.

if you replace [Flow/Facebook] with [Dart/Google] , I guess you could make the same point.

> Wondering why Dart was not considered.

Because Dart is a different language. Typescript is (mostly) Javascript with type annotations, so there is nothing new to learn. In theory, you can just change the extension of a file from .js to .ts to convert it to Typescript.

Does any major tech company use Dart other than Google?

Well can't say if any of those are major - but here is a list https://www.dartlang.org/community/who-uses-dart

I recently moved to a company using Flow from one using TypeScript, and it seems like the tooling ecosystem for TypeScript is way better than flow. The emacs plugin for flow in particular is practically nonexistent, and doesn't even provide proper syntax highlighting. TypeScript's by contrast is amazing.

I recently had to do some Node.js scripting. My JavaScript experience was minimal and having worked almost exclusively with typed languages I considered Typescript. I decided against it eventually because I figured you need to know JavaScript first to understand the JavaScript ecosystem even if you are writing your own code in TypeScript.

Does this make sense or is it feasible to skip learning JavaScript and jump directly to TypeScript?

TypeScript is, strictly, a superset of javascript. You probably could "jump directly to TypeScript" but you would not be able to "skip learning JavaScript" as TypeScript is based off the concepts in JS.

That being said, I don't see why you couldn't learn them concurrently; you can learn the basics of TypeScript and then simply rewrite any relevant JS example code into TypeScript to learn JS code in a TS context.

Edit: I should also point out that integrating with any JS libraries may require you to install the '@types/' package alongside it to maintain type-safety. For example, if you're using jQuery, you can install the '@types/jquery' package which will expose all the type information for the jquery package.

The downside of going straight for TS is that it's a bit more work to figure out how to build and debug (with sourcemaps) if you're not too familiar with front-end development.

On the other hand the upside, and a very big one, is that if you set up the relatively simple TS build process, you automatically get all the ES2015+ stuff for free, even without needing to figure out Webpack and Babel and the like (with some caveats front-end-wise, primarily Promises and Fetch).

You need to understand JavaScript and the ecosystem. Even if you're going to be writing TypeScript, other people will probably be using regular JavaScript. But TypeScript is a superset of JavaScript, so it shouldn't be very difficult to pick it up. You need to learn to crawl before you can walk, as they say.

If you want to develop an in-depth understanding of the language, I suggest reading through the ExploringJS [0] series. It covers pretty much every single edge case and detail. You don't have to read each book cover-to-cover, you can just skim parts you're familiar with.

To give you an idea of how awesome it is... Exploring ES6 is my go-to reference for anything related to ES6. When I first discovered the book I'd already been writing ES6 code for a while, and I thought I knew everything there was to know about it. But upon reading it, I was blown away by how many things I hadn't been aware of.

[0] http://exploringjs.com

> Does this make sense or is it feasible to skip learning JavaScript and jump directly to TypeScript?

It's definitely feasible and it will even save a few headaches. It's especially good for learning the API because, of course, it provides intellisense.

I find myself downloading type definitions for JavaScript libraries because it's often a quicker form of documentation than the library's official docs.

> I was more worried about not understanding other code and libraries that are written in JavaScript style.

There isn't much stylistic difference; TypeScript is not a huge departure from JavaScript.

Short answer is yes. TypeScript to JS is kinda like C++ to C.

You can learn one before the other and a lot of the skills are transferable.

I didn't expect TypeScript to be a problem. I was more worried about not understanding other code and libraries that are written in JavaScript style. It seems a lot of design patterns used in the JavaScript world make sense once you understand the strengths and weaknesses of JavaScript.

You'll need to understand JavaScript. One of the things I like about TypeScript is that it tries to 'fit' JavaScript, but the consequence is that you need to understand JavaScript to be proficient in TypeScript.

That said, I suspect it won't be too difficult, and quite worth your while, to learn 'idiomatic JavaScript' if you have experience with at least one other language. And especially with ES6 (which is 'included' in TS), if you have any experience with Ruby or Python you'll be fine with JS and it might even be a relatively pleasant experience.

Typescript is very similar to ES6 (new JavaScript). You can probably learn both with TS. You might not learn the weird JS quirks if you have to go back to ES5 at some point though.

Reddit should stop promoting their app on every freaking action you do on their website. I refuse to install because of it. Just build a better website.

Javascript is a weakly typed language and no superset like Typescript or Flow will solve this problem, just mitigate it.

However, on the other hand, I think that a good, experienced developer has no problem with that. The bugs that the experienced developer "fears" have nothing to do with type errors, which at the end are rather easy to solve...

Types can turn all runtime exceptions in to compile time errors. See: https://www.infoq.com/news/2017/05/elm-zero-runtime-exceptio...

I assume you're not claiming that experienced developers never have runtime exceptions, or that they're always easy to solve.

> The bugs that the experienced developer "fears" have nothing to do with type errors, which at the end are rather easy to solve

Not sure how you define "experienced developer", but I think you got it backwards.

A good type system enables you to structure your code in a way that most sublte bugs are "converted" to type errors. That's the magic of types!

Your type definitions aren't just some syntactic sugar so that the type checker finds some typos.

Your type definitions are a vital part of the code base that you design to protect it from changes that introduce subtle bugs - the kind of kind you can easily foresee when you wrote a particular module, but which others (or yourself after 6 months) won't be aware of. This is especially important on refactoring, but also super helpful for non-trivial extensions.

In that sense the types are like unit tests. Although they are less flexible than unit tests (so they are no substitute), they make most of your unit tests unnecessary and are shorter and easier to write and to maintain than those unit tests. Most importantly, however, they "test" all cases, statically at compile time, not just the specific cases of your unit tests.

Good reply, but the benefits you described are already realized by strong typing, which is not the same as static typing.

A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code. Thus, those are bugs that are trivial to solve.

And this, to paraphrase your post, protects your code from changes that introduce subtle bugs.

You can also have a language that is statically typed but that has weak typing! Which language? C. And i think everybody knows the extra effort needed to keep a C program bug free. And this not only due to lack of automatic memory management!

I have been programming for most of my life, that is about 23 years of programming on where 20 of those years were using statically typed languages, including many years programming on large, business-core systems on Java and C#. I since have gone to dynamically typed languages and never looked back. You just need strong typing, that's enough.

A compiler verifying against a static strong type system proves certain properties about your program which provides some assurances about what your program can and cannot do.

You might be able to prove more assuring properties about your program with a test suite.

When the GP said:

> A good type system enables you to structure your code in a way that most sublte bugs are "converted" to type errors. That's the magic of types!

I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execute the program and force it into these errors - presumably using a test suite.

> A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code.

A static type system does not need type specifications/signatures "everywhere" in your code. In Java and C#, it does. But many modern languages, TS included, can infer static types to a large extent.

As much as I am disappointed that Nim wasn't chosen, I am impressed that it was mentioned at all. Nim's JS backend is still rather young, and tooling is definitely lacking. But you can make some pretty cool things with it[1].

1 - https://picheta.me/snake/

Yeah, I did a double take when I saw it on the list. We use Nim at my new work extensively for some back end stuff (mainly homomorphic encryption experiments, but a full implementation of Paillier is also in it!) and I've just started getting the team to leverage it for the front-end too :)

That's awesome. Can we expect a blog post from you about Nim in the near future? :)

The intellisense you get with TS is quite nice, as is improved refactoring. I also think typing in function signatures is a good thing and increases comprehension.

But the type-safety you get with these kinds of static languages only catches a few trivial bugs. There are also some situations where TS complains where it shouldn't, for instance it doesn't handle JS' built in reduce function very well.

In the end, it's a trade-off between the benefits and added costs. It is in no way a given that adding static typing to your JS project will be beneficial when all factors are considered.

By contrast, does anybody think that having "stronger" dynamic typing (don't convert strings to numbers as implicitly, etc.) like Python's would not be a huge benefit?

That's actually one reason why I often opt for TS. While the 'stronger dynamic typing' isn't the most sexy benefit, it has saved my ass quite often.

There are so many situations where my input is strings (JSON through various API's) that should get turned into just integers, floats or (string) constants shortly after being consumed. Using TS types from this point onward promotes discipline to do so on my part, removes any ambiguity going forward, and alerts me if I treat these values as strings or any other wrong type (which commonly happens to me, at least, when using vanilla js).

I agree - one thing is noticing bugs, which is easier with stronger dynamic types.

And as you say it's also important to setup some boundaries so that bad values can't travel to the other end of the program before you notice, which is a pain to debug.

I like to make value checks on module boundaries, but do much fewer checks inside modules. I typically do this using assertions. Optional types can be a way to do it with less noise. But they still can't replace asserting arbitrary invariants, like invariants involving multiple values.

TypeScript is an excellent language.

I've been using TS since it's .8 days, and love it - but I think it's stretching things to say that it's an excellent language. It's a pragmatic language that makes JavaScript (which is an awful language) tolerable.

No it's not. It has all JS flaws - it's just better than js and it's easy to use it with js. Otherwise Dart would win.

I don't see how Dart wins at anything, really.

It's an extremely conservative language, offering little to nothing interesting that would make anyone switch from other solutions.

The ecosystem doesn't help it either:

For the frontend, it's stuck in a middle ground where it requires a JS interop layer (unlike TS, where it's typings are just an extra) but doesn't offer anything significant like Elm, BuckleScript, F#, ClojureScript and so many other great languages do when it comes to expresiveness. It doesn't even have algebraic data types, something TS does.

For the backend, it competes against almost all the frontend languages (due to node or native) as well as the big boys with huge ecosystems, variety of paradigms and amazing performance.

For mobile it has Flutter, which competes with Xamarin, Kivy, Qt and other bring-your-own-widgets solutions (deal-breaker for some apps and teams). In this case, Flutter is something I wanted to try out since those other solutions left me wanting and so did React Native, but Dart being such a lackluster language completely put me off of it, now having to turn to native with Kotlin after all this time looking at (and somewhat helping develop) the x-plat ecosystem.

I don't doubt that Dart will remain healthy for a long time due to Google's investment in it, but honestly, even if Fuchsia ends up being Android's succesor and Flutter ends up as its graphical toolkit, I'd instantly start looking for languages targeting the Dart VM or native interop.

> "other solutions left me wanting and so did React Native"

Could you please give specific examples of where you felt RN let you down? (Also, did you use Expo or vanilla RN?)

Thanks

" offering little to nothing interesting that would make anyone switch from other solutions"

Huh ? Compared to JS - Dart seems like a heaven. Don't known Elm - but looking on syntax it seems it's not so easy to pick up as for someone with Java/C# background. It's true Dart is not another fancy lang - it's very pragmatic.

I've been digging a bit into Dart as I've read through Fuchsia's docs and poking around with the source.

It looks like a great language, but I think it hasn't done well on the web because it has very poor interop capabilities with JavaScript and its ecosystem. I'll note that I haven't dug that deeply into Dart, so maybe there's some great resources I've simply missed so far.

TypeScript and Flow are both great options because they work completely with existing codebases. They can be adopted gradually and integrate well with the ecosystem.

Another language that looks promising is Reason [0]. It's still very young, but they seem to be working hard to create an awesome language with a great interop story. Check out their getting started [1] guide. Most of the info related their interop is in the BuckleScript User Manual [2].

[0] https://facebook.github.io/reason/index.html

[1] https://facebook.github.io/reason/gettingStarted.html#javasc...

[2] http://bucklescript.github.io/bucklescript/Manual.html

Like what? TypeScript is careful to avoid a lot of JS's footguns (implicits, undefineds, etc.)

TS has nice features to avoid js bombs but all JS 'bad code' is legit by definition (JS superset). TS is super nice compared to JS but it is NOT excellent Lang.

== versus === and all the other weak typing wats, undefined type still exists in typescript, no integer type, UTF16 strings are the ones coming to my mind and I don't even program in JS/TS

TypeScript addresses many of JavaScript's type-related issues but retains other JavaScript insanity: bizarre array semantics, Unicode ignorance, no integer arithmetic, regex facepalms, Math weirdness, etc.

Can someone please _prove_ that types make development somehow safer and more productive?

I for example believe that readability matters, and typescript is not that, compared to Python or even coffeescript.

And I really don't like how all the cool new languages lack significant whitespace.

You can probably tell I'm a Pythonista. A Pythonista always pays his technical debt.

I think this [1] is one of the better references I've seen on this question. It's an analysis of bug-counts across Github projects. There's a correlation between number of lines of code and bugs. And there's a correlation between languages that favor simplicity and bugs. But there's not a a correlation between static typing and bugs.

So, I think we can say that you don't choose static typing in order to write fewer bugs.

I've worked in lots of code-bases, both static and non. Indeed, the bug rates are fairly consistent across them. The worst code bases I've seen (from a maintainability perspective) were actually old C++ and Visual Basic ones.

Refactoring is easier in statically typed code-bases. But, in my experience, it's not significantly better. What makes a bigger difference is immutability, functional purity (within reason) and a preference for obviousness (as opposed to, say Ruby-like magic which makes me pull my hair out on a semi-daily basis).

[1] https://dev.to/danlebrero/the-broken-promise-of-static-typin...

Apparently nobody can prove type systems are more productive, or point at studies showing a benefit...

And still, everybody agrees, according to the down votes. That is frustrating!

> And I really don't like how all the cool new languages lack significant whitespace.

Significant whitespace is redundant in the face of auto formatters. The latter are becoming more popular, and rightfully so.

Auto formatters still make you look at the braces... and typescript needs a lot of those. It's not just about formatting...

I tried typing functional programming library Ramda using TS, and got frustrated it still had some limitations (e.g. needing overload codegen in lieu of variadic support).

I tried finding what TS can do now, and figured out type-level tuple iteration, among a few others. The current roadblock seems to be getting function return types. Progress, for anyone interested: https://github.com/Microsoft/TypeScript/issues/16392

At this point I'm amazed how close we are to typing anything, despite having only 5 (!) type-level operators, with their respective warts.

Gotta comment ... I dove into TypeScript about a year ago and dropped it. I saw the value but because of a large number of libraries and custom components of my own, switching purely to TypeScript wasn't easy and I was in a hurry.

Fast forward several months and I picked it up again. I've now been writing everything that I would have done in JS in TypeScript and have built several applications using both Angular and React entirely in TypeScript. I've also sold my teammates on switching to the language.

When I was (stuck) writing JavaScript, the frustration factor was high for me. I'd get nebulous errors[0], hunt around the line it referenced, swear a little, and trace the code back to the cause. I would wildly estimate that one out of ten attempts at blindly running my code would succeed[1]. Even on unit tests, which had a higher degree of success since they were testing much less, still had a much higher fall-over[2] rate than I get in typed languages that I enjoy. The addition of types, which adds a little overhead, flipped that over. I am still surprised every time I refresh a page that uses code I'm modifying and it loads. The reduction in time spent debugging (and swearing) makes me enjoy the language more every day that I use it. It's even left me longing when I am writing code in other languages (mostly Java/C# these days) and features I have come to really enjoy (union types, intersection types and to a lesser extent the duck-typing nature of the language[3]).

Since crapping on any language, or feature/lack of feature of a language tends to become a religious war fought with verbal violence, allow me to admit a few points: Traditionally, I avoided JavaScript and jobs related to it. Personally, I hate the language. This means I've spent considerably less time researching all of the best practices/techniques for surviving those cases where I have to write JavaScript. I started in C and Pascal and prior to a few months ago spent 99% of my time in typed languages. I am an advocate for unit testing[4], but I find test-driven development requires me to work backward and it's less productive for me. I'd imagine that if I went all in with TDD, I might see fewer of these problems, but many of the best practices for JS development are best practices in the languages I am more proficient in and despite following these practices, JS design led to these practices being less effective at reducing bug frequency. Yes, I could just be a yelling 'get off my lawn' because I'm unwilling to change[5]. But I've also worked closely with highly-skilled JS developers who could rapidly produce incredible things as a result of its flexible, dynamic typing. Incredibly, though, one of those 'huge JavaScript advocates' was the one who told me to give TypeScript a chance late last year. Though he would always fight me on the "dynamic vs. static" thing, his argument was that TypeScript's type system was light-weight enough to keep out of his way while strict enough to lower the frequency of self-inflicted foot bullet-holes (paraphrased). Really, though, ... two nulls, asinine boolean implicit conversions necessitating code like double-bang and === / !== operators[6] should be enough.

[0] Often depending on whatever framework I was using, but I've rarely found one that returns an error that results in a really obvious 'oh, I know what I did to cause that'

[1] I like to check that a component renders visually appropriately and often do a quick check before I've written all of the required unit/integration tests to make sure it's rendering accurately (right data/right result).

[2] As in, something fails badly enough to stop execution rather than just failing on an assert for an incorrect result.

[3] It's a love-hate thing for me -- the result is being able to reduce boilerplate making mostly-compatible types interact, but the down-side is that the compiler giving a pass to "A=B" when "A" has at the properties of "B" results in some subtle bugs that have already bitten me more than once.

[4] Though I don't buy into TDD (either before writing the code or after) solves most of the issues of dynamic typing. I've had more than a few tests fail because of a type-related issue...in the test.

[5] Except that I love learning new languages and 'keeping up' and have found that as I've aged, I can pick up new languages far more quickly than I could in my early 20s... [plug]RUST![/plug] I'm also not terribly old, nor terribly sensitive about being called an oldster.

[6] I don't recall who, but someone was once reading code out-loud and said "if action fuckin' equals 'ADD' and payload.Length doesn't fuckin' equal zero". Adding in the fuckin' every time he encountered the "really, really [not] equals" operator. So that is how I mentally read those. I'll never forgive him (sorry for the swears ... and doubly sorry if you end up reading code like this as a result).

upvote should be a global with capital letters. but writing it like that might be a leaky abstraction of the underlaying database storage. should the web dev really have to know that some variable is represented by a tinyint later converted to a float, then "optimized" to a 32 bit int !? why make it into a failure point when there is so little gain in performance and make little sence in a high level, lose typed language such as javascript. stop writing javascript like its java!

>Should work on both the client and the server. SEO is very important to Reddit, so lack of universal rendering is a deal breaker.

This sounds like a total non-sequitur.

From the article:

> Typescript also came with a lot of “social proof” and better assurances about its longevity There are several large projects using Typescript (examples include VSCode, Rxjs, Angular, and Typescript itself),

While I agree with the sentiment, I don't understand why they include "Typescript itself" in this list. Isn't that a circular argument?

Not really. It's direct proof that the language is good/fast enough that the people creating it chose it for themselves. The flow team, for example, wrote their language in ocaml.

Typescript as a project might be bigger than the rest. E.g. compared to flow the typescript repo has double the stars and quadruple the commits. If those metrics mean anything.

I would like to know if they are moving towards a SPA architecture and, if so, what framework they will be using.

Yes, using React. You can see what they're moving towards on the new profile pages like https://www.reddit.com/user/kn0thing

The mobile experience is a single page app. It's not very good.

Agreed. I don't see the use case for Reddit to be a SPA. Given that it's a list of documents linked together, I can't see a better use case for a plain old static hypertext document.

If you land on the desktop site, it consistently pushes you to download the app, and buries the mobile link.

It is an incredibly ham-handed way to try to push people into the app. Extremely irritating.

The mobile site seems to already be a SPA. Clicking on comments or the next page button shows a loading image, while the top header sticks around.

https://github.com/reddit/reddit-mobile - React / Node.

> Should work on both the client and the server. SEO is very important to Reddit, so lack of universal rendering is a deal breaker.

Are client-side only JavaScript applications not handled well by the likes of Google et. al. today? I was under the impression that they run a full JS interpreter.

https://www.stephanboyer.com/post/122/does-google-execute-ja...

Its still nowhere as accurate nor as good SEO wise. It means you don't get zero SEO, but if you want to be at the top, you want to do everything you can.

Even if/when google can spider it, other spiders can't, and social sharing tools like Facebook and Twitter can't

I would have more confidence in the list if they spelled ClojureScript correctly.

I suppose I'll piggy-back this off your comment, since mine doesn't really deserve to stand at the top level, but I am also surprised this blog post can't stylise TypeScript correctly...

The screenshot in the header is strange. Why would they reimplement arrayToDict function instead of using lodash's _.indexBy

I personally skipped Coffescript, Javascript Generators and Angular.

And none of them passed the test of time.

So I think I made the right call by not adopting them super early.

I think I'm going to do the same with Typescript. Hopefully static typing will be adopted by ES.Next and then I'll port my programs to it.

Er, JS generators definitely did pass the test of time and are now part of modern JS.

With async/await there's not much of a case for their use anymore, though

The regular generator use (return a lazily-evaluated iterator) still exists.

In fact, they are how async / await is implemented.

I wonder what are the chances of Typescript becoming (part of) ES.Next. It joins with plain JS as seamlessly as possible.

See this thread: https://esdiscuss.org/topic/es8-proposal-optional-static-typ... Note that things have moved a bit, and we're now only a few standing proposals away from being able to properly infer the challenging functions mentioned there.

From what I know of the Reddit community and their feedback on anything any of these "new devs" have done, it's not going to matter how pretty, well-typed or "scalable" (whatever that means) the code is.

All the new product is just awful. I feel sorry for them.

Anyone know existing open source projects written in Flow?

There are quite a few. I know some Facebook projects are.

From the top of my mind https://github.com/styled-components/styled-components.

Here at Streak with have 10s of thousands of lines of code written in Flow. Our main app and the InboxSDK are not open source but we do have some smaller open source libraries on our github. Check them out!

https://github.com/StreakYC

Everything updated in 2017 (so from react-float-anchor and later) has flow types included.

ok. i get why you chose typescript.

however, why did you choose this weird cursive-ish monospace font? and...where can i get it?

Operator Mono

https://www.typography.com/fonts/operator/

Its so easy to know who programs a retina screen... those newer monospace fonts with decorations look like crap on my windows pc.

Lord that font in the header image is disgusting. Who would want a faux-cursive programming font?

I thought it was an adorable font that made the comments read light and whimsical, but then again I shipped a product that used Comic Sans as its main font.

I had a very difficult time reading it as well, but then, I couldn't handwrite in cursive to save my life, so there's probably a correlation there.

I assumed this font was for marketing purposes only; regardless, I also assume that they let their devs customize their own IDEs look-and-feel, so to each their own.

It looks like there are at least 2 different fonts there. With different fonts used for different parts of the syntax. Which actually seems like a good idea, to further visually distinguish different things beyond just color. But to work right you need to choose fonts that are very visually different.

I turned off syntax highlighting long ago. You may find you don't need it.

You either understand the code or you don't.

Anyone knows what that font is?

Operator mono I think. It costs a lot.

It's actually pretty good. I have no idea how or why, but it's pleasant to the eye and very readable.

... It's probably not worth $200 though.

Buy why are you redesigning the site? It looks fine as it is. Let me guess some designer told you to redesign it in order to justify his paycheck.

"We picked Typescript because this is what we feel everyone else is using and wow are we late to this party"

Take nothing away from TS but the mobile Reddit is all the proof in the world that no matter the language, the paradigm or the ecosystem, someone can still use it to turn out a horrible product.

Using quotation marks with false quotes is a pet peeve of mine. It misleads the reader, and is essentially admitting to setting up a strawman.

Reply on news.ycombinator.com