Replace CoffeeScript with ES6(robots.thoughtbot.com) |
Replace CoffeeScript with ES6(robots.thoughtbot.com) |
Those features will be (or already are) ported to CoffeeScript.
And the CoffeeScript sugar is just tastier.
ES6 syntax is kind of CoffeeScript for people who hate meaningful indentination and it's quite decent for that purpose.
(Weak)Map, (Weak)Set, Symbol, Generators, Promises, Modules, Proxies... these aren't sugar.
Promises, modules we already had. Native implementation doesn't provide new functionality, just picks winners.
I'm really excited by generators and proxies but those are available in latest version of CoffeeScript already.
But for me that one bit of syntax is a lot less that the multitude required for many languages.
For something even more syntactically minimal there is Forth.
Many people don't like that CS needs to be compiled. I don't see this as an issue since pretty much every application I work on these days is concatenated and uglified. So adding a JS compiler is already part of most JS application's build process. 6to5 is being compiled to ES5 anyway. Also, if you include in your build pipeline a source mapper, debugging is not a problem.
The "I understand CS code much quicker" argument is a valid one theoretically, but In my opinion, it does not hold up practically that well.
CS got one thing wrong that Python got right: There are many ways to do things.
When writing CS, I understood MY CS just fine... but it always took me longer to understand the CS of other people. Sometimes even longer than JS. This is such a huge drawback, and even if there is coffeelint, for teams, this is deadly.
A lot of devs need to read a fair amount of foreign code. Even worse a lot of coffeescript writers also need to read and understand a lot of JS code.
Understanding and reading YOUR code slightly faster gets mitigated by having longer to understand foreign code.
While some JS purists fail to see that Coffeescript has some benefits, CS people also underestimate how "quickly" you can understand JS code, if you're experienced. It's all about what your brain is trained to do.
In my opinion, with ES6, I would argue for most people (ceteris paribus) it just makes sense to read and write JS exlusively, if you want to maximize output-productivity of a full, practical project.
Shaving off a couple of seconds "understand-time" of your personal, well written CS vs well written JS will just not compensate other things that will take you longer to do with CS.
Of course you can reduce the JS verbosity with JSX instead... which again is introducing a pre-processor to the mix (one I personally am not a fan of, but w/e).
ES6 adds some sweet stuff for sure, but IMO it doesn't make JS a pleasure to work with yet (which seems to be the argument?).
I'm willing to bet it's not going to reduce the count in this list by much. https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
I'm comfortable writing either as I'm sure many are, but when given the choice I opt for CoffeeScript.
P.S. Good luck telling someone using ClojureScript that they should switch back to Javascript.
I don't think this is necessarily true anymore, if it ever was. For hash-like datastructures in Python, please choose between object/dict/namedtuple/enum. In JS/CS all higher-level manipulations are dealt with through functions, whereas in Python depending on the situation you need factories, decorators, metaclasses and so on. And on a purely practical level people are moving away from the standard library (instead preferring arrow, requests, various unittest replacements etc.) but you'll still want to know the stdlib equivalents in case you encounter them in other code... and I can keep going like this.
I'm not saying this is necessarily a bad thing, sometimes one-size-fits-all just doesn't cut it, I just don't think Python can lay claim to being a simple language anymore.
Hopefully you realize that most Rubyists will strongly disagree and think that's not a "problem".
I know this might not sound like a big deal in the grand scheme of things, but I also don't think CoffeeScript really improves on js all that much, so the annoyances of source maps are just not worth it to me personally.
It's much easier to read indentation than it is to match up pairs of brackets in your head. In other languages, if the indentation doesn't match the brackets, you'll naturally read the indentation first and get the wrong impression of what the code does. In those languages, the indentation is supposed to match the brackets anyway. Why be redundant like that?
Your last paragraph makes little sense as you should never, ever be debugging a problem on live and I think minification has caused me a problem like twice in the 8 years since it's been popular. And it was pretty obvious when it did as the is wasn't even compiling.
Until you have to
Development builds should use concatenated and minified .js code. That verifies that the development build performs exactly like the production build.
You can use source maps to help with debugging.
CoffeeScript is a fun little experiment in what's possible when you take JavaScript semantics and try to boil down the user interface to a minimalist surface. But JavaScript will always keep on rolling onwards — and to the extent that future versions of JavaScript take any minor inspiration or reference or overlap with things that CoffeeScript already does, the more the better.
For example, see this talk from four (!) years ago: https://www.youtube.com/watch?v=QTj6Q_zV1yg
There's more than one way to skin the JavaScript cat.
In other news, CoffeeScript 1.9.0 came out yesterday — with support for ES6 generator functions. A-la Python, in CoffeeScript, a generator is simply a function that "yield"s.
> * CoffeeScript is an attempt to expose the good parts of JavaScript through syntax that favors expressions over statements, cuts down on punctuation noise, and provides pretty function literals.
That said, I hope it slowly fades into the background as more people go back to vanilla ES6 or go with something more powerful such as TypeScript (or Flux). With the progress around es6 and es7, gradual typing, macros, and other tooling around the language, I think CoffeeScript risks becoming a drag on getting people to learn modern JS and instead sticking with a language that has a lot of ambiguous constructions and fewer and fewer advantages over JS.
But the future of CoffeeScript is bleak because many software designers are beginning to understand the value of type systems, e.g. TypeScript and Flow, for building maintainable Javascript code bases, and this means CoffeeScript is out of the picture for good because its long term design goal is to remain a minimalistic language, and doesn't intend to support these ideas. There have been attempts[0] to fork it to add a legitimate type system to it so it can scale, but they have faltered. Aside from that, the way CS deals with variable shadowing[1] makes it risky to use in large codebases.
So when ES6 syntax is tolerable and stable, I will pack my bags and move over to the ES6 land with great regret. I wish I could stay in CS land for longer, but you have to put away childish things eventually.
------------
[0] https://www.npmjs.com/package/typed-coffee-script
[1] http://stackoverflow.com/questions/15223430/why-is-coffeescr...
It's also worth pointing out that CS and ES6 aren't really comparable technologies. ES6 isn't some newfangled preprocessor that simplifies syntax, it's an update to the standard which JS adheres to. CS is fundamentally limited because it compiles to ES5.1. When ES6 is implemented in browsers, CS will be able to do more.
-------------------
[0] elm-lang.org
it solves a lot of the problems that CoffeeScript is trying to solve without drastic syntax changes.
You can start using transforms that provide features other than ES6: https://6to5.org/docs/usage/transformers/
So from my perspective ES6 is the best of both worlds - the better syntax of Javascript and the features that Coffeescript gave you.
But it's not an objective fact that coffeescript's syntax is better. I prefer ES6. And even if you prefer coffeescript, it seems strange to claim that the most critical feature is purely aesthetic.
It seems better to treat JavaScript as admittedly not being the most powerful language in the world, and to treat the standard as a kind of RFC that only compiler writers have to think about. For most programmers it works to just use CoffeeScript (or Lisp or anything) without worrying about standards, just as JavaScript programmers don't need to worry about how their processor works.
Kind of a Java plugin that runs on web, instead of just tunneling through it.
http://kangax.github.io/compat-table/es6/
The main laggard for now is Safari/WebKit.
Developers are excited about new language features not because of browser support, but because it standardizes patterns they were already using (fat arrow functions, Promises, modules, classes, etc.) through CoffeeScript and third-party code.
(6to5 didn't even exist six months ago.)
And yes, this can be said for almost any tool choice, but my spidey sense tells me the half life for CS is about that of something like Jira.
Team size varies between 8 to 15 people, roughly.
ES5 has Function.bind
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
var Person = function(name) {
var self = this;
self.name = name
};
Person.prototype = new function() {
var prototype = this;
prototype.sayHello = function() {
var self = this;
return "Hello\n\n-- " + self.name;
};
};
var me = new Person('Peter');
console.log(me.sayHello());
On that basis, if you must do this, I would suggest `var _this`, `var scope` (though that would probably be confusing if you had the misfortune to be using Angular), `var me` (unless you happen to find anthropomorphism distasteful) or... well, anything other than `var self`, really.
Also when working with external libraries and dependencies, I found myself resorting to trial and error figuring out the correct syntax because nearly all documentation is written in JS and not CS.
Classes:
There is no semicolon after the function name
The function keyword is omitted
There are no commas after each definition
`${1 + 1}` <- why not just # like everyone else?
` Now we have a 3rd
string delimiter`
$("button").on("click", () => {
// really? hanging parens? no function keyword?
});
var [first, , last] = [1, 2, 3]
// thats a var to assign vals inside an array
// and just two commas touching to ignore a value
Besides coffeescript is just a tool.
You mean like CS? '#' actually isn't a very popular choice for this.
The significant spaces thing was ironic given that Python is kind of the biggest competitor of Ruby (×) in the modern scripting languages space. Personally it's the main reason I'm not using CS (or Python or HAML or Slim), transpiling is number 2.
(×) kind of because Ruby is probably more successful in web development but less anywhere else.
In my opinion Ceylon nailed it:
class Person(variable String firstName, variable String lastName) {
shared String name => firstName + " " + lastName;
assign name {
value names = name.split().sequence();
firstName = names[0] else "";
lastName = names[1] else "";
}
}
Unrelated: A simple class like that shouldn't be mutable.
TypeScript is pretty good at giving you a taste of ES6, it brings in a lot of features from ES6, such as the new classes, default arguments, generics, as well as a few of it's own features (interfaces, optional static type checking).
They ship it as a node module, so you can just "npm install -g typescript" and it's ready to go. As much as I dislike Microsoft, Typescript is something that seems to work well, and unlike Coffeescript, I can quite happily paste in standard Javascript code (even most ES6 code) and it won't break my source.
Short braceless code typesets beautifully, but you can probably get a similar effect w/ an appropriate 'braces highlight at lower contrast when autoindented as expected'.
To replace one tool with another, you need a compelling reason...and "it's almost at feature parity" is not that.
Other than that, the braces/indentation issue alone will keep people with CS. Can its compiler emit ES6, by the way?
Unfortunately, they didn't solve this with ES6.
.my-div %h1 Some Text - some_ruby_code
vs the ERB of
<div class="my-div> <%h1> Some Text </h1> <% some_ruby_code %> </div>
As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-)
I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got their editors set up correctly. The larger the team, and a fortiori the number of teams, the bigger that overhead is. Smacking people about the head with PEP8 goes quite close to solving the problem in the Python world, but CS's Rubyish commitment to TIMTOWTDI militates against that.
"It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less."
Because HTML and CSS, despite their verbosity, are linguae francae. A CSS file is valid SCSS by definition - a less technical prototyper person can give you their code (perhaps even generated code from some wysiwig monstrosity) and you can refactor over it to remove redundancy, enforce conventions etc using the special SASS sauce. The SASS syntax does not.
A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible' with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very, very ugly and a dreadful idea, and I'm not sure if it's possible to mix the two in similar template languages (Jade etc).
Point is: there is a human factor involved in picking shinier toys. I like HAML/Jade type templates, and Coffeescript for that matter, but I am far more comfortable using them on small teams or solo projects.
That being said, you're absolutely right, folks who write in Coffee should also absolutely eventually learn all the tips and tricks behind vanilla js also if they don't want to be bogged down.
This isn't an issue for node projects as you can simply `require` the `coffee-script/register` module and node handles coffee scripts for you via normal `requires`.
* Optional braces and parenthesis. Results in visually cleaner and more compact code, especially when dealing with large objects.
* Requiring backticks to do string interpolation seems like an ugly hack.
* CS uses dots to slice and splice ranges:
host?.split(".")[-1..][0] == "dns"
* The existential operator `?` soaks up null/undefined references.
* `==` is compiled to `===`
* Expressions always return a value in CS, just like in Lisp, so no need to explicitly `return`
* Block strings and regular expressions.
And more: http://coffeescript.org/
Plus, CS just seems like it's always a step ahead of JS. In using it, you can code in a more intelligently designed language that enforces best-practices better than JS does. Doing so supports diversity, innovations (after all, many of these ES6 features are obviously inspired by CS).
Why abandon such a wonderful language when it still has so much to offer, and at the same time seems to be driving innovation in JavaScript itself?
This seemingly minor feature is so huge for me. Accessing deep objects?.is?.a?.horrible?.pain?.sometimes?()
Don't forget, Python is the community that brought us "There's Only One Way To Do It".
https://github.com/purescript/purescript/wiki/Recommended-Li...
The dev versions of IE/Firefox/Chrome/WebKit are up to 70%/69%/48%/28% respectively.
Writing semicolon-free code is easy. Just put a preceding semicolon before any lines beginning with: ( [ + -
But I think PureScript is a more practical choice for targeting JavaScript. (It generates much smaller, more readable output, for one thing.)
I don't promise to have my mind made up, though. I'm still furiously taking in all of this Haskelly stuff, and it looks like a pretty long road ahead.
I've been telling people that I feel like I've crawled into a tunnel, and can't back out again. I seem to have no choice but to keep crawling towards that tiny beam of light.
I don't know how many times I'd looked at the ML family, and just couldn't appreciate it immediately enough... but somehow I've managed to become completely obsessed, to the extent that anything less really turns my stomach.
It's a syntactic convenience, but it leads to questionable patterns. Do you really want to silently collapse the hierarchy of whatever was null? I'd rather identify it and fail with a specific message or behavior rather than generically.
The only times it bites me is when I accidentally mix spaces and tabs in the same block, which could use a warning.
The syntax of both Ruby and Python beat squarely any C-like language, even if Python looks strange to me. Perhaps is the mix of objects and functions that makes it look a little C-ish, or the many __name__ one has to write in same cases. Anyway...
I would do without JavaScript's {} () and ; or Ruby's end (which bugged me a lot 10 years ago) but unfortunately that easier syntax is offset by the too many times it came biting me with nasty bugs after I cut and pasted code around during refactoring. Or having to take really care of how many spaces I'm deleting to match the indentation level I must reach. The editor can't autoindent all the file for me. It's bad enough when I'm working in YAML files (the format of Rails's i18n db, another ironic choice) and I don't want to deal with it in all my codebase.
So in my experience significant indentation is evil because as a matter of fact is making me less productive. Lot's of people share the same feeling, lots of people are happy with that. No problem, there are so many choices that we can always pick what's best for us.
PS: I just thought that maybe an editor could autohide Ruby's end (or color it almost away) and still be able to autoindent code. Maybe I'll try to tell emacs to color end in dark blue (black background) and see what happens to code readability.
My interpretation of what Retozi is saying is that CS just means that in addition to understanding JS, including ES6, you need to be familiar with all the different ways things can be done in CS.
I tend to agree, especially as JS is becoming an improving with each release.
What I'd like to see going forward is JS continuing to add selective sugar as is in CS, but also add functionality that makes going into a new fresh JS codebase and making sense of it easier. That side of things is less about CS, and more about the sorts of ideas you see in Dart and TypeScript.
http://arcturo.github.io/library/coffeescript/07_the_bad_par...
To each his own, but to me CS has been and continues to be a complete and obvious win over JS. 9 times out of 10 the benefit outweighs the annoyance of requiring a preprocessor for me.
[1] http://ceronman.com/2012/09/17/coffeescript-less-typing-bad-...
Commit hooks will help you:
http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
The bigger your team, the more you need them.
The LS2 issues are from years ago and nothing is happening.
I just cannot emphasise this enough. One of my skills is debugging, everywhere I've worked I've been one of the top debuggers if not the top debugger.
Never, ever debug on live. If you can't recreate the problem locally, you don't understand the problem yet. Keep trying to replicate it until you do. I'm talking days of trying, not 10 bloody minutes.
The key to all debugging, the very fundamental skill, is consistent replication. If you can replicate a problem consistently, you can fix it.
There's a class of problems where this isn't necessarily true, especially for desktop apps, but web development problems and javascript, you can almost always replicate locally.
While I agree with your overall sentiment, in any kind of remotely complex environment you sooner or later come across problems that you have no sensible way of reproducing in dev, and which will require you to debug on a production environment without it saying anything about the quality of your development process.
I have seen production hardware or wiring be the problem once in my entire career. And I used to work for a company that ran and supported enterprise software on hundreds of different client-owned servers.
Most people these days will be running a few web servers at most.
EDIT: Worse still, we're talking about debugging javascript here, which makes what you're saying even more preposterous. Wiring, indeed.
I am guessing you have not been exposed to highly complex live environments. What you say is largely true but you state it as an absolute fact, which is a bit naive. Live environments tend to be far more complex than test or local environments and sometimes that complexity is what creates the bug. Sometimes the only solution is to debug live, but of course that is a last resort.
I'm not naive, I did actually say "almost always" and "There's a class of problems where this isn't necessarily true", but perhaps you can't read?
I feel this is statement is a tad hyperbolic.
One of my key skill sets is debugging, I'm pretty good at it. One of the things we can't do is completely replicate a production environment because we're a web hoster. Sure I can run and test stuff against our OS "gold images" but when you've added third party client code running on 300-400 sites on a single server that environment is not reproducible without a herculean effort. We also don't have the luxury of time to "Keep trying to replicate it until you do. I'm talking days of trying".
Four or five times a year I need to dig out ADPlus, point it at a customer's worker process and tell it to snapshot and dump when certain conditions/triggers occur. I then whip said dump over to my WinDbg+SOS environment to find out what the hell was happening in the process when it went bad.
I haven't come up with a better approach than simply agreeing on a convention with your team though TBH. It's not too bad when everyone's on the same page and familiar with the gotchas (same could be said for most langs).
I put together a post comparing some of the syntax differences as it relates to building ReactJS components in case you're interested: http://rapin.com/blog/2015/02/03/reactjs-with-coffeescript/
Given that JS itself has quite a few different ways to do things though, it's kind of a wash.
It's much easier to read indentation than unindented/badly indented pairs of brackets, but you're setting up a strawman - it's not either or - and then you tear down the strawman yourself by pointing out we match the indentation anyway.
My code generally is properly indented and has start/end markers (though I mostly write Ruby, so rarely brackets), but what makes me stay away from significant indentation is that in the 30+ years I've been coding, I've never gone long without coming across situations where indentation has broken "in transit" e.g. with cut and paste between systems in annoying ways, or someone loading the code into an editor that butchers the indentation with tabs using "non-standard" tab settings.
When that happens, I'd rather "get the wrong impression" than have the code be broken.
That's one reason I want redundancy. My tools can trivially and automatically fix the result of breaking indentation when the indentation can be derived from the code.
Additionally, I want the visual redundancy, much like I find it far more comfortable to read syntax highlighted code even though it conveys no additional information.
The way things are in bracketed languages, humans and computers read different things, and you just have to hope that they always match up. Sometimes they don't, and the human and computer will have a misunderstanding. To make it a real linguistic redundancy, like in Spanish, the compiler should read both and issue a warning if the indentation is incorrect or misleading. As it is, you and the computer are actually speaking different languages.
Also, here's a gotcha I've run into where `a(b)` is considered different from `a (b)`
x a(b), c # => x(a(b), c);
x a (b), c # => x(a(b, c));
I encountered a non-obvious Python bug that was caused by mixed spaces-and-tabs: to my human eyes, the indentation looked fine - the same as previous line, but the interpreter saw a different level of indentation.
This is why PEP8 exists and people are supposed to follow it. Additionally, mixed spaces-and-tabs is a bug that causes poor readability - there's plenty of people who have their editors set to have tabstops as 2 or 3 spaces rather than 4, and your code will look wrong in their editors.
If you think there's any issues with mixed tabs and spaces in your codebase, Python provides a tool to find out - tabnanny. Additionally, any context-aware code editor will display a warning. (If you're using Sublime Text, the plugin to use is SublimeLinter - I assume there's similar tools for vim and emacs.) You can even set spaces and tabs to display differently in many editors!
It puts some icons in the margins, but I can't figure out how to get an explanation of those icons. I see a bunch of !s next to my import statements.
Also, computers don't deal well with it. It's a smaller problem than people don't dealing well with it (the alternative), but it's still a problem. Anyway, this is much more relevant to scripts that run inside a browser.
(nitpick: you seem to consistently use "identation" in place of "indentation".)
I'm pretty sure that plenty of proposals consistent with Python's significant indentation have been proposed; python's lambda syntax is limited due to the BDFL not being convinced of the utility of more capable lambdas over using named functions enough to want to make Python's syntax more complicated to achieve it.
> Also, computers don't deal well with it.
Computers deal fine with it.
Consequence of English not being my first language, and "indentation" being way too similar in it. I just can't spot the change.
I've seen a couple of proposals, yes they'd work, but they seem to be always ugly. But the problem is not that significant indentation makes it hard to create lambdas (Haskell's ones, for example are fine), but that it's hard to think about rules that won't create some kind of problem. On Python it's lambdas, on Haskell it's that they are often actually harder to write than explicit blocks (good thing Haskell has explicit blocks too).
And no, computers don't deal fine with it. To minimise some Python code you need almost an entire Python parser. Assembling Python code from small pieces (something that is really important for Javascript) is a frightening problem.
On top of that I find it invaluable to be able to space out debugging code. Example
void SomeFunc() {
int x = doSomething1(1, 2, 3, 4);
int y = doSomething1(4, 5, 6, 8);
int z = doSomething1(5, 6, 7, 9);
printf("xyz=%d,%d,%d", x, y, z);
int a = doSomething1(0, 2, 3, 4);
int b = doSomething1(1, 5, 6, 8);
int c = doSomething1(2, 6, 7, 9);
printf("abc=%d,%d,%d", a, b, c);
int d = doSomething1(6, 2, 3, 4);
int e = doSomething1(5, 5, 6, 8);
int f = doSomething1(7, 6, 7, 9);
printf("def=%d,%d,%d", d, e, f);
return x * y * z + a * b * c + d * e * f;
}
void SomeFunc() {
int x = doSomething1(1, 2, 3, 4);
int y = doSomething1(4, 5, 6, 8);
int z = doSomething1(5, 6, 7, 9);
printf("xyz=%d,%d,%d", x, y, z);
int a = doSomething1(0, 2, 3, 4);
int b = doSomething1(1, 5, 6, 8);
int c = doSomething1(2, 6, 7, 9);
printf("abc=%d,%d,%d", a, b, c);
int d = doSomething1(6, 2, 3, 4);
int e = doSomething1(5, 5, 6, 8);
int f = doSomething1(7, 6, 7, 9);
printf("def=%d,%d,%d", d, e, f);
return x * y * z + a * b * c + d * e * f;
}
Commenting out also because an issue
void SomeFunc(int v) {
bool doit = v > 5;
if (doit)
{
DoSomething();
DoSomethingElse();
DoSomethingOther();
}
}
void SomeFunc(int v) {
bool doit = v > 5;
//if (doit)
{
DoSomething();
DoSomethingElse();
DoSomethingOther();
}
}
def SomeFunc(v):
doit = v > 5
#if doit
DoSomething()
DoSomethingElse()
DoSomethingOther()
So no, significant indentation is not a good thing.
I guess you've developed a habit where you're completely OK with having incorrect indentation a lot of the time, whereas I can't stand it. Just because it's easier to read for you doesn't make it easier for everyone, especially beginners.
And "incorrect indentation" has a very different meaning when the indentation is purely for presentation: As illustrated above, some people like to use the indentation to call out specific aspects of the code. That may be "incorrect" from Python perspective, but it is a way of visually providing additional information that is not available to you if you use a language that requires a specific indenting style.
Sure they do.
> To minimise some Python code you need almost an entire Python parser.
I don't think source-to-source transformations requiring a parser for the source is an indication that it is problematic for computers to handle something. I mean, to execute the source code you need a parser, too, and no one says that needing a parser for execution is a sign that computers don't handle a language well.
> Assembling Python code from small pieces (something that is really important for Javascript) is a frightening problem.
Sure, assembling by cut-and-paste is a problem with significant indentation, especially when using media (like the web) which do not respect indentation well.
OTOH, using significant amount of cut-and-paste coding (rather than reuse by library code) is a sign of a problem with the language, development process, and/or execution environment, anyway, so I don't see it as a particular problem that a language structure isn't friendly to copy-paste coding.