The most underrated feature of TypeScript is not the language itself, but the transpiler. With the flick of a switch you can support ES3, ES5 and in future ES6 and beyond - without changing your code (not entirely true, but it is possible to write code that transpiles well to all JS standards).
Decoupling your development from the shifting sands of JS support - across multiple browsers and platforms - is a dream come true, and a good enough reason alone to use TS.
Totally agree. After doing a bunch of code with TypeScript (transpiling to ES5 and ES3), I decided to give Babel a try. It took me awhile to set it up properly with the right presets and plugins. It did a fine job transpiling, but I wondered why people just don't use TypeScript. It's so much easier to use.
because I enjoy writing pure JS. Typescript feels like Coffeescript, which always felt like a hack to make Rubyists more comfortable. Similarly TS feels like a hack to make C#'ers more comfortable.
Ultimately, if you're going to program in JS then get comfortable in JS, rather than trying to make JS more like your favourite language.
Some people like types, other people don't. Some people like indenting with 4 spaces, other like 2. I was a die hard 4 space guy until today, when I was debugging a bunch of 2 space code and decided I like it better.
Your editor will however default to 4 charwidth tabs, but you can change this whenever you feel like it and that's the point. It's just a setting, so we can all have our own and then we don't have to argue about it. This morning you like 2 spaces of indent because you can see more code; but this evening you like 8 spaces because the beer makes the code hard to see. It's true that the code appears locked to 8 spaces when you view it in a browser on GitHub (and that's basically why a majority of developers use spaces still in this decade) but you can also change this whenever you feel like it by placing an ".editorconfig" file in the root of your GitHub project, little known fact. In your case, you would simply change the tab width to 2 and then you don't have to commit all your files again and ruin it for everyone who prefers 4. Serious answer.
You can type absolutely pure JavaScript, change the file extension to .ts and still get some of the benefits of the typescript compiler for absolutely free.
That's probably why a lot of people are excited about typescript. It basically is JavaScript, but optionally annotated JavaScript. It's not a new language.
Well Google already did that with Java and GWT, but it never caught on.
I guess TS being a superset of JS itself might be an advantage...otherwise it is still a new language designed for web browser programming unlike Java.
I suppose it is a fair question why they didn't just use C#.
> Well Google already did that with Java and GWT, but it never caught on.
Actually it did catch on in the enterprise world, just like Typescript. Will Microsoft be as "dedicated" as Google regarding its language? wait and see.
> Well Google already did that with Java and GWT, but it never caught on.
ClojureScript uses the Closure(sic) compiler from GWT to compile Clojure/Java to JavaScript (not that I defend this technological train wreck).
> I suppose it is a fair question why they didn't just use C#.
This would have been superb, but I think Microsoft wanted to show that they "get" web developers; just mentioning C# causes the JS pundit get jittery because someone wants to limit the amount of write-only code he is able to spit out.
There were already open source projects that tried to do this some paid projects, but they never gained traction. Microsoft also had the hind sight of DART and GWT to help point them in the TypeScript direction.
Closure does not compile java to js and closjurescript does not use any tech from gwt.
Clojurescript compiles to JS itself and then uses the Closure compiler (which is an incredible piece of tech) to compile js to js (not transpile, but actual compile).
What exactly don't you like about ClojureScript? The tooling may be kind of weird (and I believe you're out of date) but once you're set up with figwheel and something like om/reagent/re-frame you start approaching the bottom-up, truly dynamic, interactive approach to building things. Every time I hear stories of "we couldn't scale our JS until we switched to TS" it's always the case of they were developing their JS in IDEs and structured similarly to a Java application, but without having to declare types and having slightly nicer data literals...
Because you can paste in your favorite JavaScript code snippets and they work without modification. One can gradually add types to a JavaScript project at a pace of your choosing. I think a more interesting question is why add types when there is Facebook's flow. My answer: because flow doesn't help with the refactoring and other IDE tasks.
(1) The transpiled JavaScript closely resembles the source TS, making debugging easier (source maps allieviete this to a certain extent).
(2) Transpiling from a whole different language means you have to port the standard runtime, otherwise you'd lose portability and familiarity, which are the two key advantages of transpiling from another, widely used language. Also, as JavaScript often runs in the browser this means downloading the runtime.
(3) The more different the two languages are, the more likely you'll run into surprising situations where feature X in language Y cannot be implemented in its original form in JavaScript, causing subtle incompatibilities between Y code written for the "original" Y compiler / interpreter and Y code that was meant to be transpiled.
(4) As someone else mentioned, TS is almost a superset of JS, which means mixing in JS code into TS code is much easier.
> The transpiled JavaScript closely resembles the source TS, making debugging easier (source maps allieviete this to a certain extent).
High-level languages look nothing like machine code, but we still compile them to it.
> Transpiling from a whole different language means you have to port the standard runtime
That's true, but it's not a reason not to use a good language instead of a horrific one.
> The more different the two languages are, the more likely you'll run into surprising situations where feature X in language Y cannot be implemented in its original form in JavaScript
I contend that any feature of a Turing-complete language can be implemented in JavaScript.
> As someone else mentioned, TS is almost a superset of JS, which means mixing in JS code into TS code is much easier.
'I still get to use JavaScript' doesn't sound very appealing. But, of course, many high-level languages offer an escape to assembler: a high-level language compiling to JavaScript can offer an escape to JavaScript.
> What is a real language anyway?
Haskell, CaML, Lisp, Python, Go — not JavaScript, though, which is an embarrassment to our profession.
One answer is the strong compatibility story for existing JavaScript libraries. You can use d3 or three.js from TypeScript; that's a big advantage over something like Elm.
Compatibility with JavaScript source (instead of libraries) is a disadvantage. The most dangerous parts of TypeScript are the JavaScript parts: arithmetic, bracket notation, etc.
Just a warning, people said the same thing about coffeescript.
I love TS, and am finding more and more ways to inject it into old codebases. However I remember what happened with coffeescript and am sure to always clearly document my build pipeline in case someone needs to move away from TS in 5 years.
to save readers the time I've just wasted, here are the two sentences about typescript in this sales pitch for cycligent.js:
"I am able to keep the freedom and expressiveness of JavaScript to which I have become so accustomed while getting enterprise-level type checking and refactoring capabilities. Declaration of objects and interfaces is a dream."
I think these reports from the field are worthwhile. The guy is an experienced programmer. I thought it was interesting that he was a hard core Java/C# and hated JavaScript when he had to use it. Then after a couple of years of JavaScript, he fell in love with the expressiveness and ease of coding and chaffed at the restrictions of Java/C#. Then he had to do a large app in JavaScript and hit the point where he it was really painful to refactor and he missed the tools he had in Java and C#. Finding TypeScript was, as Goldilocks said "just right." The tagline of TypeScript is "JavaScript that Scales" for exactly this reason. His journey mirrors mine and probably a lot of others.
I got there from thier other article "Does Electron live up to the hype?"
I am not associated with the company. I download and tried Cycligent to see how their Elecron app turned out (I'm a big fan of Electron.) It looks like a decent git client, although it feels like a web app with the dialogs that slide in. I could get used to it. Screen shot:
>I got there from thier other article "Does Electron live up to the hype?"
tl;dr - It does
It creates applications that require at the very least three times as many resources as Qt, which is also a cross-platform tool-kit that allows you a lot of freedom (specially with QML) as well as native OS widgets using a single codebase (although probably compromising on the HIGs' patterns for each OS).
I fail to see how Electron lives up to its hype as a holy grail for cross-platform application development, unless my impression of the hype behind it is wrong.
It is just the second coming of Mozilla XUL, just that this generation hyping Electron was still on their diapers, so they haven't seen it coming and going away without living any trace of it besides Firefox and Thunderbird.
While there are plenty of things to be said about JavaScript and its ecosystem which I very much doubt you could dismiss as silly, this discussion is about Electron. Meaning, an entire browser runtime being shipped to power a simple desktop appliaction, for a small developer benefit over other cross-platform toolkits and to great detriment for the users.
And please, if you believe you are above those ad-hominem attacks, don't use them yourself.
As someone who tried out XUL back when they released XULRunner, in 2006, I don't agree at all; XUL was this weird and poorly document XML language which you could only use for desktop apps (since no other browser besides Mozilla's supported it). Also, JS on browsers was much more limited back then, so code reuse between the site and the desktop app was much less useful.
Meanwhile, Electron and their ilk use all the standard web languages, and JS is nowadays used much more (including on servers), so the code reuse is now actually useful.
From what he wrote, he was writing Java and switched to JavaScript. C# got lambda expressions years before Java, if he wasn't using them, then yes, those languages are very restrictive.
They solved most of the expressiveness problems; at least for me. And Java only got them a year or two ago didn't it?
I use typescript a lot at the moment, I really miss it now when I have to write vanilla js, but it's still not a great language. You still have to think about 'this' a lot, 'this' still causes bugs, in many ways it's over verbose because every property and method call has to be prepended with 'this.'.
yes it's the same language. You don't have to use 'this', prototypes or classes a single time in your program. It's so much saner without all that crap.
Oh come on, you're not even trying. He means, the type checking and refactoring capabilities that you want to have in a large team that relatively quickly changes composition. I.e. the kinds of teams you often find in enterprises.
I doubt Google doesn't use any of the type checking and refactoring tools that come with all Java IDEs out there. You think they rename Java methods with command-line search&replace just to stay in touch with their inner startup? Come on. They're an enterprise like any other and they use what the OP calls "enterprise-level type checking and refactoring capabilities".
I agree that it's a stupid name but I think you're misunderstanding on purpose.
>* Oh come on, you're not even trying. He means, the type checking and refactoring capabilities that you want to have in a large team that relatively quickly changes composition. I.e. the kinds of teams you often find in enterprises.*
I rarely find such large teams in enterprises.
What I usually find is ad-hoc projects, some in VB6, some targeting IE6 in 2016 still, others in J2EE with "enterprise" application servers, etc. Most done by 1 to half a dozen people. And I don't see them "quickly changing composition" -- the same persons work in the same IT deps for decades...
>I doubt Google doesn't use any of the type checking and refactoring tools that come with all Java IDEs out there. You think they rename Java methods with command-line search&replace just to stay in touch with their inner startup?
No, I mean there's nothing enterprisey about refactoring.
Well, of course. Old geeks are screwed on startups and startup-y companies.
The enterprise IT (and the financial sector, major organizations, etc) are the places where old geeks are quite ok -- if not to hire, surely to keep past 40 and 50 when they have already been working for you. The median age in an IT department in a large enterprise is much higher than in any SV startup.
I thought that too. What a bizarre phrase to apply to a language he clearly loves. Enterprise level type checking normally means supporting pretty much just the concept of "classes" (ala Java) and calling it a day - leaving the developer(s) to take the burden and create all sorts of god awful "design patterns" to work around fundamental flaws in their language of choice.
I know that is not the case with TypeScript. I believe the recent version added support for union types which is going to blow the mind of the naive JavaScript masses, for sure.
Describing any language as "enterprise grade" is rarely a good thing. Wording and phrasing is important.
I simply don't understand how can someone like javascript (or anything derived from it) when there are so many much better languages around. Can someone state some advantages for web development for example compared to ruby, python, or clojure? All I see is a slow tangled mess of dependencies and broken libraries with a package manager which lets you change already released modules and a language which is even more poorly designed than PHP. Is it just because of node.js and the promise that you can use javascript from database to frontend?
If I were to start a new project today, I would use Elm[1] for the front-end. It's a very well-designed language (reminiscent of Haskell), specifically designed with HTML and DOM manipulation in mind.
Is using elm really worth it? I have not yet tried elm, but I wonder if it's advantages really justify the increased costs that this choice might bring? Isn't elm a little bit too young?
I mean is the time you and your coworkers will need to learn it, the increased difficulty to hire skilled elm developers, the increased difficulty to find good training courses for new junior developers you hire, the increased difficulty to debug the code compared to js, the lack of third party libraries ... really worth it?
> the increased difficulty to debug the code compared to js
Elm has an amazing time-traveling debugging system: http://debug.elm-lang.org/ This is a cut above pretty much every other front-end JS framework, and languages that transpile to JS.
> the lack of third party libraries
It has JavaScript interop that's based around message-passing. The JS library is treated sort of like a service, and thus the Elm code is kept isolated from it: https://guide.elm-lang.org/interop/javascript.html
> the increased difficulty to find good training courses for new junior developers you hire
The official docs are pretty good. A good programmer shouldn't have a trouble picking it up. The architectural benefits of using Elm (that lead to a high-quality, almost zero bugs website) is IMO worth it.
Sounds interesting and I'd love to code in a real functional language instead of functional style in an imperative language. I haven't looked into Elm but isn't this going against the grain too much? TypeScript seems to be gaining traction such as with Angular 2. I mean I could code in OCaml with a transpiler to JavaScript if I wanted to but it probably isn't worth the friction.
Surely by using Elm you may improve the quality of your program, but you restrict your staffing choices down to the <1% of frontenders who either know it already, or are capable of quickly picking up a Haskell-esque language.
Either that or you commit your client to huge up-front training costs.
Or how about the scenario that goes like: "The contractor who wrote our web app in Elm left last month, but we need some bug fixes or complex feature adding. Can someone fix it? Anybody? No?"
I am a Python fan and I'm not a huge fan of JavaScript, but I do understand why many people love using JavaScript/TypeScript:
1. It's available in the Browser which opens a lot of possibilities. Yes, there are transpilers for other languages but it's not the same.
2. On the server side is really fast. In fact JavaScript is one of the fastest dynamic languages out there. Much better performance than Python (even with PyPy), Ruby or Perl.
3. With TypeScript you get amazing IDE support. Which is something that you just don't have with Ruby, Python or Perl. Yes, I'm aware of PyCharm, but it's not up to the things that you can do with VS and TypeScript.
4. I know the language has some design mistakes, especially around operators and other few things. But in the end the language is small enough and simple enough that it's easy to learn. And it's also easy to learn how to avoid the pitfalls of the language as well. So in the end that's not much of a problem. Besides that, even when the language is simple, it's still quite powerful because of its dynamicity, closures and prototype oriented programming. In the end you can be as concise as you are with Ruby, Python or Perl.
Being able to reuse the code you wrote for the server in your client code and vice versa, is in my opinion not just a small feature, it can save you a lot of time and money.
I joined a company where the backend was written in PHP and the frontend in javascript. There was a ton of duplicate code, just because the backend and the frontend had been written in different languages. By using UMD modules and switching our backend from PHP to nodejs by building a custom isomorphic framework saved us a lot of time. We now don't have two development teams but just one, it's really great having everyone write (speak) the same language and makes hiring, sharing knowledge and training much more efficient.
Yeah javascript is not perfect, but I disagree that is totally bad and that you can't write good code with it.
We also use typescript because it is not just about types it does much more for us. For example allows us to write our code in ES6/ES7 (with core-js) and transpiles it on the fly (on save file) to ES5 UMD modules. Visual Studio and the nodejs tools make it easy to debug our backend code.
The code duplication is not necessarily the result of using two different languages. On the other hand you can use for example clojure for the whole stack (Clojure for backend ClojureScript for frontend).
Best thing about JavaScript is the speed of development. Once you master it, all other languages & ecosystems feel verbose, archaic.
Modern JS (ES2015+) combined with a code style (Standard, Airbnb) is beautiful, sometimes more so than Python.
Bad modules isn't a problem inherent to JS. NPM has its faults, but the JS community is the largest, and the fastest moving of all. Everything you need already exists, and it's probably actively maintained, if not accessible for you to submit a PR.
You mean the so-called "Standard" code style? Not many people use it. Why even list it...and first? Airbnb style is the most popular one by far.
This bears repeating whenever the so-called "Standard" js style is mentioned, lest any readers think that it's actually a standard that people use. It's not. Every time it's been introduced on HN, it's been roundly criticized for the name and the lack of semi-colons.
I'm not here to argue about semi-colons. But again, for anybody who missed it - the so-called "Standard" js style is NOT a standard, it's not even a de-facto standard and it's not even popular at all. Don't use it.
Standard is a very nice style and makes for very readable code, especially for those with more of a functional background. (Standard makes JS [and TS too with tslint-config-standard] feel a lot more like the OCaml relative that it is.)
Just because you don't like the name, don't think it is "popular", doesn't mean that no one is using it or likes it. (I like it a lot, personally.)
I don't agree with this. For example I can get things done using Clojure incredibly fast. The development speed with it is simply unparalleled. And since they introduced clojure.spec you get the best of both worlds (static, typed / dynamic). Bad modules is not inherent to JS but it __is__ a problem currently. Compare it to Maven Central for example: scandals like the one happened with kik is simply impossible. What I see is that there are a lot of libraries in JS which are made obsolete within a few weeks when something new and shiny comes out but there is no depth to it. For example I had to develop a topological sorting algorithm for a frontend project and I did not want to implement my own Graph library so I picked one which had the most Stars. Needless to say that the asymptotic complexities of its operations were not documented and in the end it turned out, that an operation which was supposed to have an O(1) complexity had O(n) and the whole application blew up. The point is that most libraries are sloppy and you end up reimplementing something when all your options fail. I'm used to the Collections framework in java which is well documented and performs admirably. Another problem is that javascript carries a lot of baggage which is a result of the poor design of the language itself and you end up using a lot of transpilers which extremely slows down the compile process. An application reload for example in Clojure (if you use Mount) takes less than a second.
For me, it's first class function support. Of course, there are other "real functional languages" like Scala, Haskel or whatever, but they very uncommon.
JS is the only commonly (Clojure is very uncommon) used language with real first class functions and not some silly hack like Ruby/Python lamdas, procs, or blocks.
To be fair, it seems that Java 8 has first class functions. I can't say much about it since I didn't get a chance to play with it yet.
Sure, but I think that is the point. You can do that, but its not as convenient and becomes harder to read. And besides, those are free functions you speak of, not closures. To emulate multi-line closures becomes even more obtuse.
Sorry, I edited my comment and you may have missed it. How would you emulate multi-line closures in Python? A free function which you can pass to a higher order function is not a closure. I think you would need to create a functor, and that becomes even more verbose.
Closures are functions that can capture values/references visible in the scope where the function is defined/instantiated. They are basically a short hand way of creating function objects, functions which have data members.
I believe all functions are object in python, so you can add attributes to them, but you'd be better of creating a class with a __call__ method. Relevant scope can be captured in the class __init__.
Classes themselves can hold multiple functions/methods, and if you want a function that carries state, maybe a generator would be useful?
I think this is the point. You can do all these things, but they are all extra hoops you have to jump through when all you want/need is an anonymous on-the-spot closure.
I'll grant you that a class isn't an anonymous function, arguably it's the same with lambdas that aren't as powerful as proper function defs.
But I'm not sure this is a problem. In fact, in some ways it may be advantageous e.g. static analysis.
I'd need a use-case for the anonymous closure, but a generator is a basic concept in python, so I son't think it's any trickier than a js function.
I know how in js there is a degree of 'binding' scope and hiding functionality in closures - I think in python (for better or worse) things would by convention be implemented differently.
As an aside, would you say js scope/closure approach is a bit similar to the approach in R?
"lambdas that aren't as powerful as proper function defs" I don't really follow this. I think we should use the right tool for the job. I don't need something that is "more powerful" but comes with extra verbosity and requires me to jump around the source code if I'm not using the extra power.
"In fact, in some ways it may be advantageous e.g. static analysis." Curious why static analysis can't handle closures? Also, I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle. There may be cases where you are tied to a certain language and analyzer, but in the general case, I don't follow this argument.
"I'd need a use-case for the anonymous closure." I don't want to delve too much into the usefulness of closures, but they definitely exist for a reason. They are useful as parameters to metafunctions for example, which are used extensively in certain programming styles (ie, more functional styles). Closures are basically syntactic sugar. You don't need them, but they can really make things cleaner/simpler in some cases, and are natural constructs to use in certain paradigms. They can also be used in factory functions as a more succinct way to create an object (point might be lost if you are not familiar with this style).
"I know how in js there is a degree of 'binding' scope and hiding functionality in closures." I'm not really talking about this, or JS in particular. I'm really just talking about the concept of a closure which you can find in many languages. Python already has closures (lambda), but why they can only be one expression instead of multiple lines seems somewhat arbitrary, besides maybe ease of implementing the language/problems specific to Python implementation (can you explain this one?). From a purely programming perspective, I shouldn't care about what a language has trouble with, I care about using high level and expressive constructs, I don't want to limit my expressiveness because of some technical issue in a language. Many languages implement closures efficiently.
"As an aside, would you say js scope/closure approach is a bit similar to the approach in R?" Haven't really used R, but in the languages I have used with closures, they all are basically the same. Really the wikipedia article on closures captures this.
A named function should be easier to track due to it being named, and properly defined in one place.
I believe debugging can be harder when you see some random anonymous function and have no idea where it is defined (because, I think, lambdas don't hold their definition line-nos?)
Since we're talking about multi-line functions, the added verbosity wouldn't be a lot. Additionally, you would be forced not to nest functions too much.
> why static analysis can't handle closures
Would it require tracking run-time state/modifications to the closure?
> I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle.
You could argue the same for any language with types - why should I be limited by the constraints of the type system?
Because it's easier to verify the code, and it doesn't actually limit what's possible to develop, only how it must be developed (in a more explicit style).
I see it as putting an extra burden on the developer, which makes it harder for sure, much as writing tests puts an extra burden on the developer.
> I don't want to limit my expressiveness because of some technical issue in a language
I feel this is a problem with js (versus, say, Java) - faster to write, harder to analyse. What's so important about expressiveness that you wouldn't want the code easier to maintain?
> Many languages implement closures efficiently
I can't really complain about this wrt Python when I'm not sure what it would add. Even if lambdas could be multi-line, I would not want to use them for sake of their parameter-binding semantics - in fact, I consider it a python gotcha. I
Java is a different best. It is used for a lot of enterprise projects but you don't want to use it on your own hobby projects. You can't get things done in time.
I used Clojure for three years before realizing that all of the dynamically typed languages you listed still have the same hard problems: making large code changes and reasoning about existing code. I also realized that in the real world, technical superiority is overrated, and the difference between these languages is overestimated.
Javascript is ubiquitous, runs in the browser + server, everyone I meet in the wild has to know it, and it has static typing options. It's not easy to shove those aspects under the rug to justify another language. It takes something else, mostly depending on just who I'm working with and then on what we're building.
It does not make a difference whether the language is bad or the tool is bad because if in this case npm is a de facto tool for the ecosystem you will have to use it. Same with java: it is not the language which is problematic but the "enterprise" projects which need all kinds of factories/builders/etc which make development incredibly slow.
Are you using npm? How many js developers use it around you? 90%? 95%? As I said in my previous comment it does not make difference in the end whether the tool is bad or the language. If I have to use that tool to leverage the good parts of the ecosystem (eg. use all the libraries in nmp) I can either choose not to use it and lose the the advantages of it or choose to use it and have a crap software which is in the hands of a private company and who can take over my packages (even which I have published years ago) without question.
Yes, I use npm every day. So what? You are still blaming the tool for the bad things people are doing with it.
As for the taking over packages problem, that's an easy thing to prevent. You can use the tools from npm without allowing that private company from messing you up. Download and use them locally.
When you compare pip to npm, it's a no brainer, npm wins that battle. Pip is getting better but so is npm.
Js code looks a lot like python to me now as well, especially when referencing generators.
The speed of development is it's strongest advantage. However I do think that from an architecture point of view something like golang could be considered more sound.
As I'm not a deep coder, what are the advantages of having an integer type versus a float type in the case of Javascript? Memory? Not having to use Math.floor, Math.ceil, or Math.round in case of funky divisions? I've used Javascript for years now without worrying over that particular detail.
Commands and ports are something I have carried over to typescript and it has been really beneficial. I really like the idea of treating the interface with javascript as just another service.
Well, if English were statically typed, the compiler would have caught your spelling mistake before you submitted your comment.
Types are valuable for any size application. They bring order to a chaotic world.
If you don't do static typing, you have to do a lot more unit testing. You also have to type out a lot of code to convert your function arguments into the types that you actually wanted. So, you're spending your time either way. Specifying types up front takes way less time than writing unit tests or converting arguments.
> I fail to see what typing and a typo have to do with each other to make that joke worthwhile.
Well to be fair it's more about static analysis vs catching typos though they tend to go hand in hand. I suppose a more apt analogy would be transposing a letter in the sentence where it was still spelled corrected but the part of speech changed from a noun to a verb.
I think even in large applications its not well suited because the type system has an 'escape hatch' in the form of any and null/undefined. IMO Elm is probably a better candidate, or Flow if you like the more imperative syntax.
I have had a lot of trouble explaining the benefits of static analysis, type interfaces, generic types, etc. to my js dev colleagues.
I think that what it breaks down to is that a chunk of your education is missing, and you won't "get it" until you catch up.
There are gigantic advantages to leveraging the compiler while developing. It makes refactoring a breeze, testing intuitive, and it gives you an additional safety net before deploying code.
Sure, there are benefits to writing vanilla js. I still do it from time to time while prototyping. However if you are writing javascript in a professional context on an application that needs to be stable, testable, and maintainable by a potentially distributed team, then Typescript is a no brainer (for front-end, back-end the debate rages).
I took a look at Facebook's Flow type checker for Javascript seems like it would really help with a lot of the authors complaints but would still get to right mostly plain JS.
132 comments
[ 3.2 ms ] story [ 230 ms ] threadDecoupling your development from the shifting sands of JS support - across multiple browsers and platforms - is a dream come true, and a good enough reason alone to use TS.
Ultimately, if you're going to program in JS then get comfortable in JS, rather than trying to make JS more like your favourite language.
That's probably why a lot of people are excited about typescript. It basically is JavaScript, but optionally annotated JavaScript. It's not a new language.
I guess TS being a superset of JS itself might be an advantage...otherwise it is still a new language designed for web browser programming unlike Java.
I suppose it is a fair question why they didn't just use C#.
Actually it did catch on in the enterprise world, just like Typescript. Will Microsoft be as "dedicated" as Google regarding its language? wait and see.
And of course Dart.
ClojureScript uses the Closure(sic) compiler from GWT to compile Clojure/Java to JavaScript (not that I defend this technological train wreck).
> I suppose it is a fair question why they didn't just use C#.
This would have been superb, but I think Microsoft wanted to show that they "get" web developers; just mentioning C# causes the JS pundit get jittery because someone wants to limit the amount of write-only code he is able to spit out.
false.
Closure does not compile java to js and closjurescript does not use any tech from gwt.
Clojurescript compiles to JS itself and then uses the Closure compiler (which is an incredible piece of tech) to compile js to js (not transpile, but actual compile).
Ask HN: If TypeScript is so great, how come all notable ReactJS projects use Babel? https://news.ycombinator.com/item?id=12537614
(2) Transpiling from a whole different language means you have to port the standard runtime, otherwise you'd lose portability and familiarity, which are the two key advantages of transpiling from another, widely used language. Also, as JavaScript often runs in the browser this means downloading the runtime.
(3) The more different the two languages are, the more likely you'll run into surprising situations where feature X in language Y cannot be implemented in its original form in JavaScript, causing subtle incompatibilities between Y code written for the "original" Y compiler / interpreter and Y code that was meant to be transpiled.
(4) As someone else mentioned, TS is almost a superset of JS, which means mixing in JS code into TS code is much easier.
(5) What is a real language anyway?
High-level languages look nothing like machine code, but we still compile them to it.
> Transpiling from a whole different language means you have to port the standard runtime
That's true, but it's not a reason not to use a good language instead of a horrific one.
> The more different the two languages are, the more likely you'll run into surprising situations where feature X in language Y cannot be implemented in its original form in JavaScript
I contend that any feature of a Turing-complete language can be implemented in JavaScript.
> As someone else mentioned, TS is almost a superset of JS, which means mixing in JS code into TS code is much easier.
'I still get to use JavaScript' doesn't sound very appealing. But, of course, many high-level languages offer an escape to assembler: a high-level language compiling to JavaScript can offer an escape to JavaScript.
> What is a real language anyway?
Haskell, CaML, Lisp, Python, Go — not JavaScript, though, which is an embarrassment to our profession.
Compatibility with JavaScript source (instead of libraries) is a disadvantage. The most dangerous parts of TypeScript are the JavaScript parts: arithmetic, bracket notation, etc.
I love TS, and am finding more and more ways to inject it into old codebases. However I remember what happened with coffeescript and am sure to always clearly document my build pipeline in case someone needs to move away from TS in 5 years.
"I am able to keep the freedom and expressiveness of JavaScript to which I have become so accustomed while getting enterprise-level type checking and refactoring capabilities. Declaration of objects and interfaces is a dream."
I got there from thier other article "Does Electron live up to the hype?"
https://www.cycligent.com/blog/does-electron-live-up-to-the-...
tl;dr - It does
I am not associated with the company. I download and tried Cycligent to see how their Elecron app turned out (I'm a big fan of Electron.) It looks like a decent git client, although it feels like a web app with the dialogs that slide in. I could get used to it. Screen shot:
http://imgur.com/a/y5F5A
It creates applications that require at the very least three times as many resources as Qt, which is also a cross-platform tool-kit that allows you a lot of freedom (specially with QML) as well as native OS widgets using a single codebase (although probably compromising on the HIGs' patterns for each OS).
I fail to see how Electron lives up to its hype as a holy grail for cross-platform application development, unless my impression of the hype behind it is wrong.
And please, if you believe you are above those ad-hominem attacks, don't use them yourself.
And exactly where was my ad-hominem attack?
Electron is much better than XUL along many dimensions.
At least it doesn't force you to use XML external entities in DTD files for text localization. [1]
You just call the Electron localization function! ;) [2]
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu...
[2] https://en.wikipedia.org/wiki/Electron_localization_function
Meanwhile, Electron and their ilk use all the standard web languages, and JS is nowadays used much more (including on servers), so the code reuse is now actually useful.
Back then I could usually guess when some "desktop" apps were written in XUL, given their performance or lacking OS integration.
Same thing now with Electron apps.
They solved most of the expressiveness problems; at least for me. And Java only got them a year or two ago didn't it?
I use typescript a lot at the moment, I really miss it now when I have to write vanilla js, but it's still not a great language. You still have to think about 'this' a lot, 'this' still causes bugs, in many ways it's over verbose because every property and method call has to be prepended with 'this.'.
Google is bigger than most enterprises, and they don't use any "enterprisey" stuff, not even in their Java.
I doubt Google doesn't use any of the type checking and refactoring tools that come with all Java IDEs out there. You think they rename Java methods with command-line search&replace just to stay in touch with their inner startup? Come on. They're an enterprise like any other and they use what the OP calls "enterprise-level type checking and refactoring capabilities".
I agree that it's a stupid name but I think you're misunderstanding on purpose.
I rarely find such large teams in enterprises.
What I usually find is ad-hoc projects, some in VB6, some targeting IE6 in 2016 still, others in J2EE with "enterprise" application servers, etc. Most done by 1 to half a dozen people. And I don't see them "quickly changing composition" -- the same persons work in the same IT deps for decades...
>I doubt Google doesn't use any of the type checking and refactoring tools that come with all Java IDEs out there. You think they rename Java methods with command-line search&replace just to stay in touch with their inner startup?
No, I mean there's nothing enterprisey about refactoring.
Guess I've found my solution to my persistent angst over the repeated 'old geeks are screwed' stories around here!
The enterprise IT (and the financial sector, major organizations, etc) are the places where old geeks are quite ok -- if not to hire, surely to keep past 40 and 50 when they have already been working for you. The median age in an IT department in a large enterprise is much higher than in any SV startup.
It doesn't get more enterprisey than that.
It doesn't mean anything. I guess the author just meant static typing.
I know that is not the case with TypeScript. I believe the recent version added support for union types which is going to blow the mind of the naive JavaScript masses, for sure.
Describing any language as "enterprise grade" is rarely a good thing. Wording and phrasing is important.
"Modern" type checking is mostly about not writing types and strong inference
Aka
"Of the two languages I know, Typescript is my favorite."
https://www.cycligent.com/
That is all.
[1] http://elm-lang.org/
I mean is the time you and your coworkers will need to learn it, the increased difficulty to hire skilled elm developers, the increased difficulty to find good training courses for new junior developers you hire, the increased difficulty to debug the code compared to js, the lack of third party libraries ... really worth it?
Elm has an amazing time-traveling debugging system: http://debug.elm-lang.org/ This is a cut above pretty much every other front-end JS framework, and languages that transpile to JS.
> the lack of third party libraries
It has JavaScript interop that's based around message-passing. The JS library is treated sort of like a service, and thus the Elm code is kept isolated from it: https://guide.elm-lang.org/interop/javascript.html
> the increased difficulty to find good training courses for new junior developers you hire
The official docs are pretty good. A good programmer shouldn't have a trouble picking it up. The architectural benefits of using Elm (that lead to a high-quality, almost zero bugs website) is IMO worth it.
Elm also guarentees to NOT produce ANY runtime errors, that's quite a guarantee.
Either that or you commit your client to huge up-front training costs.
Or how about the scenario that goes like: "The contractor who wrote our web app in Elm left last month, but we need some bug fixes or complex feature adding. Can someone fix it? Anybody? No?"
How do you sell that to a client?
1. It's available in the Browser which opens a lot of possibilities. Yes, there are transpilers for other languages but it's not the same.
2. On the server side is really fast. In fact JavaScript is one of the fastest dynamic languages out there. Much better performance than Python (even with PyPy), Ruby or Perl.
3. With TypeScript you get amazing IDE support. Which is something that you just don't have with Ruby, Python or Perl. Yes, I'm aware of PyCharm, but it's not up to the things that you can do with VS and TypeScript.
4. I know the language has some design mistakes, especially around operators and other few things. But in the end the language is small enough and simple enough that it's easy to learn. And it's also easy to learn how to avoid the pitfalls of the language as well. So in the end that's not much of a problem. Besides that, even when the language is simple, it's still quite powerful because of its dynamicity, closures and prototype oriented programming. In the end you can be as concise as you are with Ruby, Python or Perl.
I joined a company where the backend was written in PHP and the frontend in javascript. There was a ton of duplicate code, just because the backend and the frontend had been written in different languages. By using UMD modules and switching our backend from PHP to nodejs by building a custom isomorphic framework saved us a lot of time. We now don't have two development teams but just one, it's really great having everyone write (speak) the same language and makes hiring, sharing knowledge and training much more efficient.
Yeah javascript is not perfect, but I disagree that is totally bad and that you can't write good code with it.
We also use typescript because it is not just about types it does much more for us. For example allows us to write our code in ES6/ES7 (with core-js) and transpiles it on the fly (on save file) to ES5 UMD modules. Visual Studio and the nodejs tools make it easy to debug our backend code.
Modern JS (ES2015+) combined with a code style (Standard, Airbnb) is beautiful, sometimes more so than Python.
Bad modules isn't a problem inherent to JS. NPM has its faults, but the JS community is the largest, and the fastest moving of all. Everything you need already exists, and it's probably actively maintained, if not accessible for you to submit a PR.
PHP? Lol, no. JS > PHP.
If you need concurrency, Facebook's Hack has support for async/await and some other nice things.
I'm not saying this is necessary better, just that PHP has a bad rep that it may not deserve at this point (which is pretty similar to JS imo)
This bears repeating whenever the so-called "Standard" js style is mentioned, lest any readers think that it's actually a standard that people use. It's not. Every time it's been introduced on HN, it's been roundly criticized for the name and the lack of semi-colons.
I'm not here to argue about semi-colons. But again, for anybody who missed it - the so-called "Standard" js style is NOT a standard, it's not even a de-facto standard and it's not even popular at all. Don't use it.
Just because you don't like the name, don't think it is "popular", doesn't mean that no one is using it or likes it. (I like it a lot, personally.)
That is pure opinion.
To be fair, it seems that Java 8 has first class functions. I can't say much about it since I didn't get a chance to play with it yet.
Classes themselves can hold multiple functions/methods, and if you want a function that carries state, maybe a generator would be useful?
But I'm not sure this is a problem. In fact, in some ways it may be advantageous e.g. static analysis.
I'd need a use-case for the anonymous closure, but a generator is a basic concept in python, so I son't think it's any trickier than a js function.
I know how in js there is a degree of 'binding' scope and hiding functionality in closures - I think in python (for better or worse) things would by convention be implemented differently.
As an aside, would you say js scope/closure approach is a bit similar to the approach in R?
"In fact, in some ways it may be advantageous e.g. static analysis." Curious why static analysis can't handle closures? Also, I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle. There may be cases where you are tied to a certain language and analyzer, but in the general case, I don't follow this argument.
"I'd need a use-case for the anonymous closure." I don't want to delve too much into the usefulness of closures, but they definitely exist for a reason. They are useful as parameters to metafunctions for example, which are used extensively in certain programming styles (ie, more functional styles). Closures are basically syntactic sugar. You don't need them, but they can really make things cleaner/simpler in some cases, and are natural constructs to use in certain paradigms. They can also be used in factory functions as a more succinct way to create an object (point might be lost if you are not familiar with this style).
"I know how in js there is a degree of 'binding' scope and hiding functionality in closures." I'm not really talking about this, or JS in particular. I'm really just talking about the concept of a closure which you can find in many languages. Python already has closures (lambda), but why they can only be one expression instead of multiple lines seems somewhat arbitrary, besides maybe ease of implementing the language/problems specific to Python implementation (can you explain this one?). From a purely programming perspective, I shouldn't care about what a language has trouble with, I care about using high level and expressive constructs, I don't want to limit my expressiveness because of some technical issue in a language. Many languages implement closures efficiently.
"As an aside, would you say js scope/closure approach is a bit similar to the approach in R?" Haven't really used R, but in the languages I have used with closures, they all are basically the same. Really the wikipedia article on closures captures this.
A named function should be easier to track due to it being named, and properly defined in one place.
I believe debugging can be harder when you see some random anonymous function and have no idea where it is defined (because, I think, lambdas don't hold their definition line-nos?)
Since we're talking about multi-line functions, the added verbosity wouldn't be a lot. Additionally, you would be forced not to nest functions too much.
> why static analysis can't handle closures
Would it require tracking run-time state/modifications to the closure?
> I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle.
You could argue the same for any language with types - why should I be limited by the constraints of the type system?
Because it's easier to verify the code, and it doesn't actually limit what's possible to develop, only how it must be developed (in a more explicit style).
I see it as putting an extra burden on the developer, which makes it harder for sure, much as writing tests puts an extra burden on the developer.
> why they can only be one expression
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
Seems like it is mainly a technical decision.
> I don't want to limit my expressiveness because of some technical issue in a language
I feel this is a problem with js (versus, say, Java) - faster to write, harder to analyse. What's so important about expressiveness that you wouldn't want the code easier to maintain?
> Many languages implement closures efficiently
I can't really complain about this wrt Python when I'm not sure what it would add. Even if lambdas could be multi-line, I would not want to use them for sake of their parameter-binding semantics - in fact, I consider it a python gotcha. I
Defining a lamba `foo = ->(x) { x * x }`
Calling it `foo[10]` or `foo.call(10)`
I don't see anything hacky about that at all.
Javascript is ubiquitous, runs in the browser + server, everyone I meet in the wild has to know it, and it has static typing options. It's not easy to shove those aspects under the rug to justify another language. It takes something else, mostly depending on just who I'm working with and then on what we're building.
Ah yes, let's blame the tool for the bad things people do with the tool.
But again, you are blaming the tool for the bad things people do with the tool.
As for the taking over packages problem, that's an easy thing to prevent. You can use the tools from npm without allowing that private company from messing you up. Download and use them locally.
Js code looks a lot like python to me now as well, especially when referencing generators.
The speed of development is it's strongest advantage. However I do think that from an architecture point of view something like golang could be considered more sound.
We use JavaScript, but in 90%+ of our codebase we use it without 'this', without prototypes, without classes, and without other ugly parts.
As I'm not a deep coder, what are the advantages of having an integer type versus a float type in the case of Javascript? Memory? Not having to use Math.floor, Math.ceil, or Math.round in case of funky divisions? I've used Javascript for years now without worrying over that particular detail.
Seriously though, Elm's error reporting is best in class.
Not just because of the compiler errors, but also because of its other limitations, like having your effects isolated via `Cmd`s and ports.
Well, if English were statically typed, the compiler would have caught your spelling mistake before you submitted your comment.
Types are valuable for any size application. They bring order to a chaotic world.
If you don't do static typing, you have to do a lot more unit testing. You also have to type out a lot of code to convert your function arguments into the types that you actually wanted. So, you're spending your time either way. Specifying types up front takes way less time than writing unit tests or converting arguments.
Ha! I love seeing things like this on HN and think it's a perfect example to illustrate the power of static typing. Kudos!
Well to be fair it's more about static analysis vs catching typos though they tend to go hand in hand. I suppose a more apt analogy would be transposing a letter in the sentence where it was still spelled corrected but the part of speech changed from a noun to a verb.
I think that what it breaks down to is that a chunk of your education is missing, and you won't "get it" until you catch up.
There are gigantic advantages to leveraging the compiler while developing. It makes refactoring a breeze, testing intuitive, and it gives you an additional safety net before deploying code.
Sure, there are benefits to writing vanilla js. I still do it from time to time while prototyping. However if you are writing javascript in a professional context on an application that needs to be stable, testable, and maintainable by a potentially distributed team, then Typescript is a no brainer (for front-end, back-end the debate rages).