Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

FAQs: es6 roadmap, choosing an implementation, tooling #4078

Closed
Labels
@SonOfLilit

Description

@SonOfLilit

I'm doing research prior to adopting Coffeescript for a young startup's codebase. After intensive googling, I found no clear answers but many people asking themselves the same questions, so it may be a good idea to amend the FAQ with answers to these:

  • What is the roadmap for ES6 support? When will features be supported? (When ES6 is standard? When it is supported? Never? Per-feature? How is it decided?) What kind of support can be expected? Will it break backwards-compatibility?
  • I understand that this implementation is considered best practice and Redux is dead code? Is this correct?
  • What is considered best practice tooling for working with Coffeescript?jslint?coffeelint? Anything else different from what you'd use with vanilla JS?

Thanks.


A discussion we had today on IRC:

<sonoflilit> Hi<sonoflilit> I'm considering moving our young startup's codebase from js to CS, and am concerned about future ES6 support<sonoflilit> Is there a roadmap somewhere that I'm missing?<sonoflilit> also, is best practice to use CS or CSR?<apanek> sonoflilit: Regarding ES6, I would say: unconclusive :) https://github.com/jashkenas/coffeescript/issues/3698<apanek> sonoflilit: Personally, I find CS without classes a lot more comfortable to work with than plain JS in any way. I'm not sure porting all the codebase is necessary though.<apanek> I'd go with writing new modules in CS as you see fit and porting old modules when you change them - given you want to use CS. It also makes for an easier way back if you plan to not use CS anymore.<sonoflilit> we're still a small enough codebase that it makes sense to use js2coffee once and get done with it<sonoflilit> but I'm afraid of the community dying<sonoflilit> and translating back from CS to js isn't as trivial, because you get code with so many insurance clauses that it's unreadable<apanek> I can't tell. Since I started my devops job, I didn't really do any client-side work.<sonoflilit> so this is a one-way decision<apanek> If you look at the issues of jashkenas/coffeescript, the discussions seem alive.<sonoflilit> it does indeed<sonoflilit> is tooling around CS going to remain alive?<sonoflilit> is it even meaningful, or do you all use exactly the same tools js programmers use?<sonoflilit> apart from `coffee`, of course<apanek> I never used special tools.<apanek> I don't know whether there are any :)<sonoflilit> e.g. a linter<apanek> There was a coffee --lint but it was removed in favour of JSHint according to the changelogs.<apanek> The old coffee --lint command has been removed. It was useful while originally working on the compiler, but has been surpassed by JSHint. You may now use -l to pass literate files in over stdio.<apanek> ""<sonoflilit> so this is not best practice? http://www.coffeelint.org/<apanek> Oh cool :)* apanek is not up to date<sonoflilit> gotta say, an almost empty IRC channel is quite concerning<sonoflilit> or is it me living in the wrong side of the world?<sonoflilit> 6:32AM in the valley, yup<apanek> I can't tell. There's not too much going here, but people stop by every now and then to discuss things or ask questions. Most of the project communication is probably on Github.<apanek> I'd suggest asking those questions on Github as well, you might get more up to date answers and probably also an answer from jashkenas.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp