TypeScript Seals My Penchant for JavaScript
cycligent.com
cycligent.com
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.
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.
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.)
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)
That is pure opinion.
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.
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.
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.
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?
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.
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.
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.
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.
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.
(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.
Ask HN: If TypeScript is so great, how come all notable ReactJS projects use Babel? https://news.ycombinator.com/item?id=12537614
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 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#.
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).
And of course Dart.
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.
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.
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).
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.
"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:
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?
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.
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
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.'.
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.
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.
"Modern" type checking is mostly about not writing types and strong inference
Aka
"Of the two languages I know, Typescript is my favorite."
That is all.