Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparison with babel-sublime #20

Closed
franciscolourenco opened this issue Apr 12, 2017 · 4 comments
Closed

Comparison with babel-sublime #20

franciscolourenco opened this issue Apr 12, 2017 · 4 comments

Comments

@franciscolourenco
Copy link

How does this package compare to babel-sublime?
Any advantages?

@JoshuaWise
Copy link
Owner

JoshuaWise commented Apr 12, 2017

javascript-ultimate is the only syntax out there that highlights errors in your code. Usually if you type something that the syntax doesn't recognize, it will leave it unhighlighted, like a normal variable name. But javascript-ultimate actually traverses your code and highlights syntax errors with a "bad" color.

javascript-ultimate also follows the ES6 spec exactly, while most syntax plugins are just the author's understanding of the language and usually they miss edge cases in the language. javascript-ultimate also has pretty advanced regular expression comprehension.

@franciscolourenco
Copy link
Author

@JoshuaWise would you say the only feature babel-sublime has over javascript-ultimate is support for JSX?

@JoshuaWise
Copy link
Owner

JoshuaWise commented Apr 12, 2017

I haven't extensively studied babel-sublime, but I believe that assessment is likely to be true.

@bathos
Copy link

bathos commented Jun 8, 2018

This is my first time coming across this definition and as the author of Ecmascript Syntax, which operates similarly ("only syntax out there that highlights errors in your code" isn’t true, though it may be the case that this one does so better), I’m curious to know more about how they differ. If this covers all the same territory as ES Sublime (or if it could w/ some contributions), I would consider closing up shop on it in the interest of reducing fragmentation of tooling.

Some context re: ES Sublime —

  • the main goal there was to provide much more specific scope targets than existing defs
  • current with ES2018
  • covers a number of proposed features (decorators, class properties, etc)
  • covers JSX
  • happens to mark many invalid tokens as invalid, but as a side effect of the approach rather than a key objective, which I think is a difference from the angle here
  • follows the spec to most of the extent that’s actually possible (a bit confused by "perfectly accurate" claim here — does this have a Python component to overcome the linebreak blindness constraint?), but in expressions does fall back on heuristics at a certain point (due to left recursion realities)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants