The only reason why this is becoming more of a "thing" nowadays, at least on blogs and in the media, is because the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea, at least in practice on a grand scale. As a job, many web developers (myself included) use JavaScript only when absolutely necessary, and it's really just to make things "look nice". At work, JavaScript is not the thing that drives our entire application (in fact we have more than a few tests that ensure our apps' critical functions work even when JavaScript is disabled in the browser). But I've been experimenting with Ember, Electron, et. al., and it's pretty cool what you can do nowadays with JS alone. These new toolchains have brought and will continue to allow entirely new genres of web applications to be developed with ease, meaning my job gets a little more interesting. We'll probably always have/need CRUD apps, but as a web developer, your fate is no longer sealed in writing CRUD apps for the rest of your life. That's pretty neat!
No it isn't. This was written nearly 15 years ago: https://bitbucket.org/BerislavLopac/waexplorer
Some applications necessitate more sophisticated user interactions.
And you are claim that your way is simpler? To me all the thing that you rant about are just different. If things with the web rendering would started with the front-end instead the back-end, then you would be ranting the same stuff on the opposite side and you would be saying that SPA are simpler.
* Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward.
* Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one.
* Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process.
Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from:
* Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text".
* Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens.
* Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions.
My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.
Not really. While your points are all true, the two biggest factors that you can't really escape are 1) your SPA is still a 1 MB download 2) eval'ing 1 MB of JS before rendering is still slower than serving HTML.
SPAs are a better experience, but they're still slower than conventional pages, and I wouldn't recommend their use on high traffic areas of your site, like the landing page.
That's what middle-click to create a new tab is for.
> Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward.
If HN were a single-page app, I wouldn't use HN. Period.
> Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one.
Again, that's what middle-click is for.
> If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately.
Sure, that's a nice use for JavaScript. I just don't want to have to expose my entire system, and all my data, and every system I can connect to, to malware in return.
Same case with blog posts. Sites like HN would not even exist if everyone published all their posts in SPAs.
I figured out I could built simple CRUDS in minutes (literally) using scaffolding, and may a couple hours of editing for special cases.
But I got bored, and went to look for what I could do differently. How to make it "smoother". I'm sure scaffolding and quickly generating CRUD with SPA's will happen soon enough and we will move on to something like "pure browser functions" using links and changing pages statefully.
> It’s reasonable to assume "foo bar and hello world" will compile to either:
> foo(bar) && hello(world)
> foo(bar && hello(world))
I'm not really trying to come to the defense of Coffeescript here, but I think it's worth noting that adding more operators for clarity is a good thing. I even go as far as adding additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression.
Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse.
For me this was one of the greatest lessons of Clean Code by Bob Martin, in my opinion a wonderful book which completely changed and dramatically improved the way I write code. By improvement I mean simply the ease with which I can understand and modify my own code months after writing it/ seeing it last.
There's a slight contradiction here with another great lesson of that book though which is short code (by lines) > longer code simply because it's easier to consume in a single glance. There's certainly a delicate balance at play here.
It's a great thing to break down a complex process into steps, naming those steps as you go, and storing things in variables achieves that. However sometimes a better tool, and again another frequent suggestion in Clean Code (really, all credit to Bob Martin for all these ideas) is to instead break the steps into clearly-named functions, if this is possible. Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise.
Another great tool for the belt and one of the reasons I have come to always prefer programming in a functional style vs a more stateful, OO style, where I can (even within pretty OO languages such as Java - though the lambdas in 8 have greatly improved the ease with which this can be done).
I hate this lesson. And it's not because short code is a bad thing...when you find code that's well structured and broken down such that no method/function needs to be long, it's a joy to read. The problem comes when people learn the rule without learning the why behind it. And that leads to one logical function/method that's huge and has now been broken down into many nested methods/functions simply to satisfy the "none are long" requirement. Now, as a reader, I've still got to keep the entire context of the method/function in my head, but I now have to jump all over the code to find out what the single, large method actually does. I'd rather have a single, 200-line code block to look at than this sort of jumble.
What developers need to learn is that short methods/functions are a consequence of good techniques, not a technique in and of themselves and that long methods/functions are not bad in and of themselves, but they indicate that it's very likely that the developer hasn't put the proper thought into separating concerns and ensuring that each unit of his/her code has a single responsibility.
Sorry to get on my soapbox, but I've seen this "lesson" make ugly code even uglier when programmers don't understand the why behind the lesson.
Couldnt agree more, variables are just clutter you have to keep mental track of, and working with series of transformations is much easier (for me at least) to process. I would be interested to know if its like this for all developers, perhaps not, since I know some that are also opposed to recursion.
but for me this:
sum([]) = 0.
sum([H|T]) = H + sum(T).
function sum(ary) {
var i = ary.length,
res;
while(--i) {
res += ary[i];
}
return res;
}> Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse
But regardless of the truthiness of this statement, it has no value. It's like saying that no matter what you eat, in large quantities it can cause humans harm. And yet there's a clear distinction between ingesting mercury or lettuce.
Many (too many) programers seem to take a viewpoint of "only type the minimum numbers of characters necessary to get something to work." Then they make their programming goal to be the least characters possible as long as the compiler accepts their input.
complaining about ambiguity because they learn how the language works.
Some programmers also enjoy learning all the ambiguous edge cases then making sure their code fits them exactly in the way they intend, but not necessarily the way others will read the code.
That's why we end up with awful things like "if (abc) def; else hij;" or worse "if (abc) { def; } else hij;", etc. Plus, if your language isn't line-sensitive, using weak syntax but pretty alignment is just a recipe for future failures a few steps removed from when you originally introduced the future inconsistencies.
foo () (irb) :2: warning: don't put space before argument parentheses .The problem isn't "hard to parse", but rather "easy to parse --- in two or more ways".
an example that is clear and consistent, albeit contrived, would be to wrap arguments when there are more than one:
foo bar
foo (bin, bar)
or if that's too "iffy" for you, you just always wrap with parens!
E.g. (foo bar) and (hello world)
Yep. There was a previous July 2013 article and related reddit thread about it.[1] The CoffeeScript compiler devs themselves were bitten by their own strange scoping rules!
As to the other question about why people don't just write raw Javascript, Eric Lippert explained why plain Javascript is inadequate if you want to do more than just "make the monkey dance"[3] -- a.k.a. "large complex apps".
[1]https://www.reddit.com/comments/1j1cw7
[2]https://github.com/jashkenas/coffee-script/commit/7f1088054c...
I was one of the "you save characters, you gain readability" proponents as well (I love Python too).
However, it is a terribly flawed argument. Typing characters is incredibly cheap.
Debugging and refactoring in a dynamic language. However, is very time-consuming. You might be a tad slower writing Typescript (with autocompletion and typechecking, I doubt it though). But over the whole lifecycle of a codebase, Typescript is a lot faster for everything but very small projects.
I have done refactors in Typescript in hours that would have taken me days in CS... multiple times.
Additionally the human brain can adjust to predictable noise very well (brackets). After a training period, I find Javascript and Typescript almost as readable as MY Coffeescript.
However, even when developing 8 hours for multiple months in Coffeescript, I always had a hard time to grok other people's Coffeescript. There is just too much freedom.
This does not happen that easy with Javascript/Typescript.
Generally, static typing in a complex user interface is a huge huge win productivity wise. While you type more characters, you are still faster over the lifecycle of a project. Hitting keys on your keyboard is literally the least time-consuming part of programming.
You can do 20 layers of callbacks in Haskell without any problem. That's how Haskell does imperative blocks of code (ie monads).
note I'm being deliberately provocative with the above statement to promote discussion, not argument. :-)
1. most of the analytics/event-stream processing will be done on the backend anyway
2. If you are picky enough you can do functional programming in js. Reative.js is decent library for processing streams of events.
What screams to use something more haskell-like, is their example of 'Trys', i.e:
class GraphQuery extends Query {
static parse(object: any): Try<GraphQuery> {
return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => {
return Filter.parse(object.where).flatMap((filter: Option<Filter>) => {
return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => {
return new Success(new GraphQuery(
filter,
groupBy,
timeRange
));
});
});
});
}
}
parse : Any -> Try GraphQuery
parse object = do
timeRange <- TimeRange.parse object.over
filter <- Filter.parse object.where
groupBy <- GroupBy.parse object.by
return (createGraphQuery filter groupBy timeRange)
> parse : Any -> Try GraphQuery
> parse object = do
> timeRange <- TimeRange.parse object.over
> filter <- Filter.parse object.where
> groupBy <- GroupBy.parse object.by
> return (createGraphQuery filter groupBy timeRange)
parse = ({by, over, where}) => {
timeRange = TimeRange.parse(over)
filter = Filter.parse(where)
groupBy = GroupBy.parse(by)
return createGraphQuery(filter, groupBy, timeRange)
}
parse = ({by, over, where}) =>
createGraphQuery(
Filter.parse(where),
GroupBy.parse(by),
TimeRange.parse(over));
parse = ({by, over, where}) =>
createGraphQuery(
Filter(where),
GroupBy(by),
TimeRange(over));
parse = ({by, over, where}) => createGraphQuery( Filter(where), GroupBy(by), TimeRange(over) );
parse = ({by, over, where}) => c(f(where), g(by), t(over));
parse = ({b, o, w}) => c(f(w), g(b), t(o));
For the purposes of this article, we tried to avoid too much syntax sugar to make it more accessible. That aside, I'd love to add something like this to monapt![1].
> Had our first hire start today who applied because we use @elmlang in production. He rocked it!
> PS: still hiring :)
https://twitter.com/rtfeldman/status/656238188961226752
Furthermore, I’ve learned so many languages on the job in my career that I am unsympathetic to companies who refuse to believe that people who have learned programming can continue to learn programming!
On the one hand there's a smaller pool of people, on the other hand a primary issue in hiring is sifting people who can do the job from a random draw[0], in which case interest and/or knowledge of Elm or Purescript is a huge prefilter, and can draw/poach people who wouldn't otherwise be interested (pg's "the python paradox"[1] talks about that)
[0] or worse, you don't get a random section of developers, you get a section of developers currently looking for a job, so the average competence of your draft is below average.
There are plenty of developers, especially here on HN, who would absolutely love to work with Clojure/ClojureScript full-time.
1) you'll need less people (better more reusable code) 2) the best people will speak you out.
This was very much my experience when I put a Haskell team together, and everyone I've spoken to who has done the same has said the same.
It's an opportunity for a young company, not a problem.
As opposed to what? In what ways do you not consider Javascript to a be a functional language?
* Pure functions - JS functions are essentially subroutines. They might return a useful value or they might mutate a bunch of stuff and interact with the outside world. Who knows? JS functions aren't guarunteed to return the same value, or any value at all.
* Immutability - Anything and everything can be mutated in JS, including the contents of objects that are defined using the new ES6 `const` keyword
* Curried functions by default - Although it's possible to compose or partially apply JS functions, it's not nearly as nice as Haskell or Elm.
* Ambiguous syntax? Just add a few parenthesis.
* You don't like the existencial operator? Learn some JS, being able to easily differentiate between a truthy value and the existence of a variable with a single character is as sweet as it can get.
* Comparing a language to Babel? Doesn't make sense. Babel translate ES6/2015 to ES5 for compatibility. Comparing ES6/2015 to CoffeeScript makes sense.
* CoffeeScript is the reason you couldn't scale/solve data syncing or redrawable views? JS/CS/TypeScript/etc have nothing to do with that! Maybe he was thinking about Backbone?
Seems like the guy is confusing tools and languages... and making (bad) decisions because of that.
Personally I'm not going back to writing { }, return and ;'s :-)
For me, {} are better than spaces - perhaps because of habits, but what will I get in - non-effortless - changing my habit in this place? "Add a few parenthesis" advice seems the opposite - don't we want not to have to use artifacts for clarification, but have simple and natural defaults working? Etc.
Coming from many years of python development, coffeescript is a natural fit...
We had a large existing pure JS codebase, so Facebook's Flow was a better fit for us. We still have some portions of our code that don't have type annotations, and invariably that's where the majority of new bugs are introduced. Now we have a policy of making sure all the files we touch are typed, and adding types to a file if it doesn't already have it.
Types + React is a whole new ballgame when it comes to front end dev.
You can benefit immoderately from compiling your existing codebase in TS; you'll probably discover some bugs, even before adding any annotations.
There are still cases where you'll need to sprinkle <any>. For example:
var state = { foo: 1 };
if(something) {
state.bar = 2;
}
We also have an established toolchain with gulp and browserify and babel, and again, at the time TS didn't play as nicely (vs Flow which just worked). Things are definitely improving in the TS world, and I keep tabs on it. The fortunate thing is that both Flow and TS' annotations are compatible, so it should be relatively easy to switch from one to another.
Whichever one you go with doesn't actually matter though. As long as you go with one of them you'll see a massive increase in productivity vs vanilla JS.
The only thing that toke me a while to understand at the start was the whole "Definetly Typed" repo, why and how to use it. It is a bit strange to have to add types as you develop but you can live with it after it sits in.
There is also Angular 2 which mergers very well with it, friendly advice, try it!
The problem core of the problem is that many of the definitions they host are contributed as one-offs by developers who create them as needed, and often there is no one responsible for making sure they get updated in lock step with the library itself.
The only way I can think to solve this is to have a contributor to the library itself be responsible for maintaining its type definition, so that keeping it up to date becomes part of the release process. Of course, really everyone should just switch development to typescript so that the defs get generated automatically ;)
declare var SomeGlobal: any
declare module 'some-node-module' { declare var m: any; export = m }
Also, hopefully more npm package maintainers will start to add typings directly now that TypeScript searches node_modules.
If a definition doesn't match the version of library you're using, changing the definition or adding to it omly takes a few minutes.
It has seemed pretty easy to add types for the parts of the library I need, rather than the entire library. Is there anything in particular that makes partially typing server-side libraries difficult?
minus a couple of bugs which should be fixed by now.
I was to build the startup front-end with typescript, but then there were too many libraries needing manual wrapping and I didn't want to experiment too much.
Being able to have code completion in javascript is nice, but it's also something that you can work around by developing a good work regiment using browser-based debugging tools. The benefit of typescript is substantial, but circumventable. The drawback, one that I haven't seen anyone mention yet, is now having to deal with generics inside javascript. Trying to reason about this code and spending most of my cognitive focus on how the author is dealing with generics adds an entirely different complexity to reading and understanding javascript.
On one hand, it's helpful to have types. On the other, adding a very Microsofty overhead to programming using meta-data on your data and generics inside javascript makes me want to pass on this.
Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.
If you just want to write a site while using a bunch of libraries, it might be useful to use VSCode, which provides autocomplete for normal JS code, as long as at least parts of the code have typescript bindings.
That said, JS ASI is not much different than Python/Coffeescript newline rules and if you are comfortable programming semicolon free in those languages there shouldn't be a reason that you should feel uncomfortable going semicolon free in Typescript and/or JS. The nasty issues are in fact mostly the same as Python/Coffescript.
There is only a single instance I think of that is of legitimate concern - which is #4 listed on this blog [0]. The rest, to me, seem like arbitrarily shitty formatting or scenarios that never arise in an attempt to show why semicolons are needed.
i
++
j
That being said - "remove all semicolons except the times you need semicolons" is silly. I also personally dislike the look of prefixed semicolons, so I'll continue to add semicolons. But I disagree the "nasty issues" are a legitimate concern anymore than "adding semicolons where they don't belong" is a legitimate concern. Both can bite you in the ass and both require a small understanding of where semicolons are needed and how Javascript gets parsed.
Ultimately I think having semicolons will increase the amount of people who contribute - as people will be more comfortable with that style - but I think to have or to not have semicolons is a stylistic choice in the end.
[0] http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...
You may have seen this, but if not: http://standardjs.com/
I understand why people might prefer the whitespace but to me the ambiguity and extra technical debt isn't worth the payoff in readability.
I also like semicolons. Especially in javascript.
class GraphQuery extends Query {
static parse(object: any): Try<GraphQuery> {
return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => {
return Filter.parse(object.where).flatMap((filter: Option<Filter>) => {
return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => {
return new Success(new GraphQuery(
filter,
groupBy,
timeRange
));
});
});
});
}
}This makes it really easy to interop with existing Javascript code, but it also makes it really easy for non-Typescript developers to pick up.
For me, learning Typescript was pretty quick, because valid Javascript is already valid Typescript. All I had to do was remember the syntax for (optional) type annotations.
Learning ES6 was actually the bigger hurdle, not Typescript.
));
}); // I
}); // love
}); // TypeScript
}
}
TypeScript and related make a lot of sense for very large projects/teams because static type checking can be VERY useful, and the lack of a statically typed language choice for in-browser programming is a large weakness of the web ecosystem. So TypeScript is a tremendous advantage to have in the toolkit, and a much saner approach than older heavy-weight options like GWT.
I think it's telling that a lot of companies with the most mature products (Facebook, Dropbox, Asana) eventually resort to optional static typing in their products, whether that means extending their runtimes (e.g. Hack) or using a transpiler like TypeScript.
(Also I don't think optional static typing has gotten off the ground in Python land, or adopted in production at Dropbox?)
I used to use Coffee Script, which I still like, but ES6 clearly made Coffee Script less relevant. Typescript value is clearly in the type annotations and the support for ES6 ...
Another problem with Coffee Script is the fact that it evolves way to slowly and it is unlikely to support most of ES6 features because its core maintainers are clearly not interested in adding significant features. In fact that the main issue for me. Both Backbone and Underscore suffer from the same issues.
I see that a lot and find it highly subjective. I don't find es6 useful at all and will stick with coffeescript for the foreseeable future but that also has to do with my reasons for using it.
Better - it removes that ability for deliberate bad behavior by devs.
That said - I prefer JavaScript + Flow as thats a much more native solution which means you don't need to learn a pseudo language first.
- Writing JS gives me a better feel for how the language actually works
- I like the line number in the JS I'm debugging to equal the line in my source code
- There's less magic to understand & deal with
- CoffeeScript automatically returns the last line of a function, and I don't always like that
Fortunately, most everyone else seems to understand what Coffeescript is, and thus they were able to grok my meaning.
Here is a simple example:
some_func = (callback) -> callback new Error 'boom'
some_func (err) ->
return console.log err if err
console.log 'everything is fine'
This makes huge difference when you write async code and no amount of TypeScript can really help it.
let some_func = callback => callback(new Error('boom'));
let some_func = err => console.log(err || 'everything is fine'); let some_func = (callback) => callback(new Error('boom'))
let some_other_func = (err) => console.log(err || 'everything is fine')
let some_func = co(function*() {
try {
const someData = yield asyncRequest(some_url);
console.log('asyncRequest resolved with %j', someData)
}
catch(e) {
console.log('asyncRequest rejected with %j', e);
}
});[0]: http://flowtype.org/
The Flow type annotations are almost identical to Typescript. There's one edge case around one of them requiring a space before/after the colon and the other not, but I can't remember what it is. I just tried running one of the Flow examples through the Typescript playground and it worked fine[0].
The biggest differences between Flow and Typescript are how you run the build system (`tsc` versus the Flow server) and the file extension you put on the file.
[0] http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20htt...
* TypeScript allows unsound casting, Flow doesn't. These casts are very practical, as you might know more than the analyzer. Flow takes a stricter position here, which is a theme.
* Function are bivariant w.r.t. their parameters (which is unsound) in TypeScript, but contravariant in Flow. Again, this is an intentional, practical choice, but Flow emphasizes soundness.
* TypeScript asks users to add annotations in scenarios where Flow will infer types. TypeScript will infer any (there is a "no implicit any" option).
* Classes in Flow are nominal (interfaces are structural). Classes are structural in TypeScript.
* Flow adds no additional runtime syntax to JavaScript; TypeScript does (enums, for example). Flow does support some ES2016 features (async/await, object spread), but generally holds off on experimental features (stage < 2).
* Flow has a couple interesting features absent in TypeScript, like disjoint unions. I suspect/hope both systems will converge on useful features like this.
* TypeScript treats null as a bottom type, but Flow uses explicit "maybe types."
There are a ton of other CoffeeScript features I love like the string interpolation syntax, comprehensions, implicit return, @ for this, improved switch syntax, ranges and a ton of other stuff, but I'm going to hang on to those first four for as long as its practical to do so.
That aside, we'll talk about how we built our architecture in our next blog post! I promise you that I thoroughly pored over the Elm architecture tutorial[1] before designing any building blocks.
But except that, typescript has some catch up to do in terms of typesystem with Flow.
You can use TypeScript with --target es6 and then use babel as a secondary transpiler.
The bigger issue was the bugs the existential operator led to. Not worth it when checking for existence wasn't a problem in javascript anyways.
There's an Om-like UI project with bindings to virtual-dom https://github.com/boothead/oHm as well as various react bindings such as https://github.com/joelburget/react-haskell
For something that follows the semantics of JS and produces very readable code (a la TypeScript), PureScript is really nice.
It seems from the article like the reason why the dismissed it was that it interoperated poorly with existing vanilla JavaScript libraries.
http://www.typescriptlang.org/Handbook#writing-dts-files
Will your third-party-lib that doesn't use Typescript keep a dts file? Who knows...
Luckily most of the big libraries are covered; it's mainly smaller stuff - think random jQuery plugins - that aren't covered.
These are libraries which are often hacked together, lack tests, clear documentation and anything approaching support. So things that you shouldn't really rely on.
Flow is not really fundamentally different from Typescript. The syntax is almost the exact same.
I tried them out side-by-side for the same project a few months ago. The main difference was that Typescript was installable through npm and simply read and wrote files to the directory, whereas Flow required an OCaml binary and ran a client-server setup that required some fiddling to get working.
Flow is designed to work better with React, so it has that going for it, but if you're not using React, Typescript is almost exactly the same.
One problem I saw that it was heard to try out release candidates for React when they were lacking type definitions.
Apart from that I really like TypeScript.
It adds no utility outside of that niche anymore however.
TypeScript is great but I honestly prefer ES2015/ES6 + Flow comments. It means I write native JavaScript (ok, for now a transpile step, but that will go away in time and I'll still have valid JS code) but get all the benefits of typing like in TypeScript.
However TypeScript is still pretty awesome, though I find the syntax rather verbose.
* Comprehensions (more flexible with Coffeescript). Wait, that's ES7 now.
* Template strings
* For .. Of loops
* Destructing
* Classes. ES2015 has an awful implementation of this, without allowing an syntax for binding methods. Also enforces the somewhat arbitrary requirement of function properties only, as opposed to any type I choose. Don't forget, mixins with Coffeescript classes is a breeze, but no support with ES2015.
* Arrow functions. Unnecessary syntax with ES2015 (the parens even without arguments), not to mention confusing implicit return.
* Generators with ES2105. If you find a use for these in front end web dev I'll buy you a beer.
The point here is that it is frustrating to see people jump on the ES2015 bandwagon when Coffeescript has had the same feature set for years. It suffered adoption because of developers who didn't want to learn `another` language. I have met a tremendous quantity of developers - myself included - who initially rebelled against the use of Coffeescript, only to eventually fall in love with it.
Agreed. I didn't say features; I said looked. It looks horrible in comparison.
ES6/7 code is much cleaner, clearer, and more idiomatic, than CoffeeScript. (in my experience, and I've used/debugged/worked with a LOT of both)
Not going to crap all over the features of CoffeeScript, those were good (though they produced pretty awful looking JS code as a result). I would say however it wasn't worth the trade off in debugging pain.
Can we have a typescript-alike tool that integrates the "best parts of javascript" and defaults to 'use strict'? if there is one I'm in.
I found this out the hard way when using it in groovy a while back. The Options abstraction you describe is better, or the one in Java 8, which Groovy still hasn't brought into its syntax. Groovy's creator James Strachan talked a lot about how he designed Groovy to avoid the "leaky abstractions" in Java.
> I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
[1] http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl...
How does Typescript compare with Dart? Is Javascript the place to start?
We have to wait for the previous generation to retire or die before we can get critical mass on the next idea. - Douglas Crockford