I'm one of the original developers of Zulip. The long comment I'm replying to is a somewhat rant-y critique of Zulip, but it's basically valid. We honestly have a hard time communicating the stream/topic paradigm, even though in some sense it's just forum/subfora.
I encourage vanderZwan and others to come to https://chat.zulip.org/# to talk to us. We're real people. We like the app we've developed, but we know it's far from perfect, and we especially know that our marketing could use some constructive feedback.
No need to downplay it: it is a rant, and I knew it when I wrote it, but I wanted to get across the raw frustration that I think a lot of users feel. Plus, as I said at the beginning, it was more to illustrate a more general problem.
You have my respect for taking it in stride and listening to the critique! I already mentioned it does look like a good app, and based on skimming through that lightning talk (not to mention this reply by you), the dev community behind it looks open too.
I'm personally in favor of leaving JS mostly alone, especially at the syntax layer, and then let transcompiler solutions like CoffeeScript evolve to relieve the syntax burden and add semantic improvements.
CoffeeScript is far from perfect--it has syntax quirks of its own--but it's more pleasant for me to write in, being used to Python and Ruby. (And, yes, I understand JavaScript too; I just don't like the syntax.)
Eventually transcompiler languages will evolve to take advantage of different JS engine improvements. So far, this isn't a goal of CoffeeScript, but other abstraction layers might already be doing that.
Eventually transcompiler languages will evolve to take advantage of different JS engine improvements.
I wonder what opportunities there are here that haven't been exploited yet and that don't require replacing JS with a new language. For example, could JS implementors define a more-easily-optimizable subset of JS? Then transpilers seeking performance could target just that subset.
It's an interesting idea. My assumption is that stronger JS engines already do a good job of optimizing simply-written JS, whether the JS is hand written or produced by a transcompiler.
Transcompilers that were target-specific could probably target server-side JS at first. e.g. If you're just building a node.js app, there's no reason for the polyfill language to make any concessions to IE, for example. So one "optimization" is simply avoiding legacy cruft in the generated output. But I could also see exploiting specific features of cutting-edge JS engines.
One of the stated reasons for Dart is that the V8 team was hitting a wall with making JS fast, beyond which a language with cleaner and more optimizable semantics is needed. I wonder, though, whether the nature of that wall has been clearly written up anywhere. I'd like to know if there are tricks in the category of "This would be annoying to write by hand in JS, but would be easy for a compiler targeting JS" that could be used to get around it.
Transcompilers that were target-specific could probably target server-side JS
I had an idea recently that (to me at least) is super exciting: someone should make a good language that compiles (à la Coffeescript/Parenscript) to JS but also to Lua. JS and Lua are close semantically, so it might not be so hard. (If it did turn out hard, it probably wouldn't be worth doing.) That would be a really interesting server-side alternative to both Dart (whose philosophy appears to be "run our VM on the server and compile to JS for the client") and Node.js.
The tool obviously works best with a fairly wide browser window, but patches are more than welcome to improve the CSS, which is obviously kind of primitive. For simple stuff, filing an issue would be great--no need for a full-blown pull request.
Yup, there is some support for editor integration, although it's still up to you to actually glue it into your editor of choice. See the issue below for more discussion.
I agree with you that are some skeptics who will continue to move the goalposts. I also think that the tool itself won't change any minds.
My hope is that it can help early adopters get over the initial debugging barrier, which, despite the hype, is a legitimate concern. The tool can also be an aid for advocates in teaching coffeescript.
I also think that lack of line-number mappings is a fair criticism of coffeescript. If the article is rejecting FUD, then it should target statements like "debugging is a nightmare." I agree with the author's overall point that you can usually track down problems without a lot of fuss.
CoffeeScriptLineMatcher lets you see CoffeeScript/JavaScript code side by side. It's mostly geared toward debugging, but it also helps you examine the transformations made by the CS transcompiler.
I hope you change your mind about visiting the US, and the Silicon Valley in particular. If you're concerned about your safety or enjoyment while you're here, that's fine, but I wouldn't boycott the US to make a political statement. The strange minority of Americans who don't understand freedom aren't gonna get the message. Your boycott is gonna hurt the Americans who most want our country to be a diverse, welcoming place.
I highly recommend San Francisco in particular. We have a decent sized French expat population, and the city is fairly multi-cultural and liberal, even by European standards, I think. Once you arrive here, you're in driving range of stunning natural beauty--redwood forests, SF Bay, Yosemite National Park, Big Sur, etc.
I agree that matching up line numbers is usually pretty trivial, although I also see how this complicates the workflow for people. To make matching lines even easier, I've written this tool: https://github.com/showell/CoffeeScriptLineMatcher
I encourage vanderZwan and others to come to https://chat.zulip.org/# to talk to us. We're real people. We like the app we've developed, but we know it's far from perfect, and we especially know that our marketing could use some constructive feedback.