6 ms·
Mixed feelings about CoffeeScript, as ever. ES6 obviously deals with some of the issues that CoffeeScript was intended do. That's awesome. Unfortunately, it's
by matthewmacleod 9y ago
Mixed feelings about CoffeeScript, as ever.
ES6 obviously deals with some of the issues that CoffeeScript was intended do. That's awesome. Unfortunately, it's still difficult to go back to what seems like the relatively baroque syntax of Javascript afterwards, as someone who has a bit of a vendetta against over-syntax. SO MANY BRACKETS.
In particular, there was CJSX - JSX with CoffeeScript. Writing React components using it was an absolute joy in comparison, and helped eliminate a lot of noise – making it much more obvious what a component was doing.
But yeah, it's been hard to convince others that it's worth the investment, when honestly it's really just a personal preference at this stage.
- s_kilk 9y ago> SO MANY BRACKETS. }) }) }) }) }) }) }, }) }) }) }) }) }) }, Whatever do you mean?
- chx 9y agoDidn't ES6 promise ;) to solve this?
- matthewmacleod 9y agoThis is true only insofar as libraries use promises, and your code uses promises. They're still pretty annoying in my experience. There are still some other cases where the mess of brackets is overkill, other than callback hell.
- udp 9y ago> This is true only insofar as libraries use promises, and your code uses promises. They're still pretty annoying in my experience. Promisify, or (as I prefer to) just "return new Promise((resolve, reject) => { nonPromisedStuff(...) })"? > There are still some other cases where the mess of brackets is overkill, other than callback hell. Like bad coding style?
- roblabla 9y agoI'm awaiting ES7 :D for the true solution to this problem. It'll eliminate the boilerplate of .then(function() {})` entirely. Less brackets, less ceremony.
- jholman 9y agoES7 was finalized a year ago. Everything except IE 11 supports all of it. You meant ES2017. HTH
- masklinn 9y agoAnd all current browsers save IE11 support ES2017 async functions.
- zajd 9y agoIsn't ES6 `.then(()=>{})` ?
- deleted 9y ago[deleted]
- ravenstine 9y agoOr even without curly braces: `.then(x => doSomethingWith(x));`
- ulucs 9y agoPromises returning promises (or async/await which is just sugar-coating for promises) solves this very cleanly in my experience
- deleted 9y ago[deleted]
- horsawlarway 9y agoI agree. Promises have solved most our team's nesting issues. It's incredibly clear, allows clean and concise error handling, and is easy to use.
- teknologist 9y agoIt takes time to get those brackets right; time that adds up. That's one of the many ways CoffeeScript contributed to my own productivity over the years
- icholy 9y agoOnly if you're editing text with a potatoe.
- dmix 9y agoAssuming you have an editor which auto wraps pararenthesis then with Coffeescript you are basically exchanging brackets for spacing with zero productivity gain, besides some features such as list comprehension and easier handling of that = this. Additionally every JS file has to be preprocessed making debugging slightly harder and set up more involved. Every person contributing to the project has to become familiar with CS. Plus mixing both CS and non-CS files always ends up happening in my experience. As a former CS fan, I really don't see the utility of using CS like I used to.
- matthewmacleod 9y agoIf you're using ES6, you're already likely doing a compilation step anyway. So I'm not too sure there's much loss.
- dmix 9y agoTrue, I've been using Babel for ES6 when not working on chrome extensions or sites limited to early adopters which I look forward to not having to depend on. For Node you don't need Babel to use ES6 besides support for import instead of require. I still find having to use Babel annoying.
- teknologist 9y agoSo we're assuming that everyone only ever writes new code in a situation where auto insertion of parentheses would kick in and contribute. Don't you people have to edit existing code? Callback hell anyone?
- ojr 9y agothe text editors/ides I use today have bracket matching and with eslint it's been easier to track missing/extra bracket bugs, the example you have is heavily exaggerated, nesting like that is bad code with or without brackets
- baby 9y agoIt is still confusing. Look at how clear python files are for example.
- dmix 9y agoMy editor's colorscheme makes brackets dark gray and I don't use semicolons in JS because it's optional. It's really not that ugly. I What IS ugly is inspecting machine generated Coffeescript source code in Chrome dev tools and debugging it. So is having to set up preprocessors whenever you want to use Coffeescript. Which is easy in Rails but a challenge in many other scenarios such as simple static sites. Not to mention the number of projects I've joined which has a random mix of both .js and .coffee files. I'd prefer spacing over bracket if it was natively supported in the language as it is in my favourite languages Erlang, Elixir, and Haskell. But that's not the case here.
- deleted 9y ago[deleted]
- yellowapple 9y ago
- buchanaf 9y agoWho writes JS like this?
- scaryclam 9y agoThis is something I'm left wondering. I've written a lot of JS, some of it in complex applications. I've never had this issue of mass nesting that would cause all of these brackets people here seem to be complaining about. I'd suggest that coffeescript isn't solving issues with javascript syntax, but instead is allowing the kind of code that should be refactored out to stay around for longer as it doesn't look so ugly. That's not really a good thing. Perhaps it's a good thing if the community lets it die.
- maxscam 9y agoYou might not feel like you wrote too many brackets, but good luck convincing someone who uses none (except for hashes) that they should start. Coffeescript code is not sloppier, its more terse.
- z3t4 9y agoPeople who have not yet discovered named functions.
- rpeden 9y agoI've found that writing React render methods in plain CoffeeScript is actually pretty pleasant, too. I gave it a try not long ago and it came out looking pretty similar to Elm.
- matthewmacleod 9y agoYeah, I can see that. There are a few things that make it nice, like the `@` sign in place of `this, and implicit returns (which remove a bunch of boilerplate and brackets).
- rattray 9y agoI built LightScript because of this; you might give it a try. It's a rough superset of ES7+JSX+Flow, built on Babel. Integrates pretty well with a bunch of tools like ESLint, should be much more future-proof than coffeescript. Would love your thoughts if you'd like to give it a try - http://lightscript.org http://lightscript.org
- matthewmacleod 9y agoThat actually looks lovely I'll check it out!
- rattray 9y agoThanks! Happy to help in the gitter chat if you have any questions - gitter.im/LightScript/Lobby
- likeclockwork 9y agoI really appreciate the thin arrow syntax.
- WalterSear 9y agoI've work for over a year on a CS codebase and, while brackets are ugly, but I'll take visible ones over invisible ones any day.
- cookiecaper 9y ago100%. I think CoffeeScript put the cart before the horse by promising some nearly-magical block detection and then they were stuck trying to implement it. I find that CS code is very temperamental and difficult to maintain over the long term. "No brackets, it's so pretty!" is fine, but other languages don't make what feel like random guesses as to where your delimiters are, they use a different syntax to mark the blocks. Personally I prefer to just mark the blocks myself rather than hope that the compiler infers it correctly, whether that's done with indentation as in Python, keywords like "begin" and "end", or with C-style bracketing. I even find comparatively mild things like Ruby's inferred parentheses grating. There's no reason not to put an opening and closing mark. You're already thinking in delimited terms when you're writing the code, there is no real extra cost to throwing in the indicators, and it makes it so much easier to figure out what's going on when you go back to debug, when you try to read the code after months, or when your text editor is trying to help you out with folding and the like.
- maxscam 9y agoWhether or not bracket free code is more readible might be a personal opinion. I think for people who understand Coffeesctipt well, its easier because theres less visual noise. There are many languages with optional parens, and whether or not you want to stretch the ability of the parser is up to you. Coffeescript proves that they are not necessary in order to write javascript.
- braveo 9y ago> I even find comparatively mild things like Ruby's inferred parentheses grating. I agree with everything you've written and I'd like to note that even Ruby has degenerate cases where you're forced to use parenthesis around things because the parser can't figure out what you mean. I have an instant dislike for any language that tries hard to make code 'pretty' by removing such indicators. And to be clear, there's a difference between a concise version of a syntax, such as C#'s lambda syntax, and creating inconsistencies in your language by trying to remove syntax that cannot be universally removed without creating ambiguities. The former is welcome, the latter is not. Even Ruby has such degenerate cases. And I like Ruby, but I dislike that design decision.
- andrei_says_ 9y ago> just a personal preference How does one objectively measure this? I strongly prefer to read less code, to make fewer mistakes (I.e. closing brackets).