5 ms·

Really redminds me of coffeescript, lots of special syntax that doesn't really help readability? I have a hard time understanding the motivation of this projec

Really redminds me of coffeescript, lots of special syntax that doesn't really help readability? I have a hard time understanding the motivation of this project other than syntactic sugar-maxxing JS/TS.

smt88 2y ago
Languages like this don't make sense anymore. You can just pick a mature, feature-rich language you like (Rust, Kotlin, Python, probably many more) and transpile to JS.
- Yahivin 2y ago
  The GWT approach has its own downsides as well.
  - smt88 2y ago
    A) GWT is 20 years old and not similar to how modern transpilation works B) What are the downsides?
    - Yahivin 2y ago
      The built in browser debugger is incredibly good. As long as the transpilation is simple and matches JS semantics you can still use the debugger. I haven't seen good debugging tools when using languages more distant from JS but I'd love to know if they've become viable.
      - smt88 2y ago
        You've been able to debug TypeScript (and anything else that transpiles to JS) natively in the browser for years using sourcemaps. That includes Dart, C#/F#, Go (as far as I know), and Python. For the languages that target wasm instead, there are different debugging stories. Kotlin's is very good, Rust's is pretty immature.
        int_19h 2y ago
        Source maps are not sufficient to fully expose the semantics of the language being debugged to the debugger. You also need the expression evaluator (for stuff like Watch etc) to understand what it's debugging. And in cases where transpilation includes nontrivial mapping of data structures, you also need the ability to do that mapping in reverse to display the values. Source maps work great for TS because it is just "JavaScript with types" at this point.
- bfung 2y ago
  Or compile to wasm
- troupo 2y ago
  All those mature feature-rich languages started as "languages like this make no sense"
  - chrismorgan 2y ago
    That’s certainly not true of Rust: Rust had a particular goal, easily recognised as worthwhile, which wasn’t possible with any existing languages. Everyone sensible agreed the language made a lot of sense, even if they weren’t sold on the practicality of its specific approach.
    - troupo 2y ago
      IIRC everyone was perplexed why Mozilla was spending time on what looked like a research/academic problem instead of focusing on Servo
      - chrismorgan 2y ago
        I didn’t get involved with any of this stuff until mid-2013, but at the very least by then, it was well understood that Servo couldn’t reach its potential without Rust.
        troupo 2y ago
        Just to quote Wikipedia: > Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare, named after the group of fungi that are "over-engineered for survival". Mozilla began sponsoring the project in 2009, and would employ a dozen engineers to work on it full time over the next ten years So by 2013 it was already 7 years old. I very much doubt the original personal project was viewed as "a lot of sense" etc.
        chrismorgan 2y ago
        You’ll always easily find plenty of people that will say “that makes no sense”. But of people that worked in these sorts of fields, I imagine that, from the very start, there would have been significantly more than average approval for its goals, even if you wouldn’t expect it to succeed (such endeavours normally don’t). The niche Rust was targeting from the very beginning was one that was known to be underserved, and known to be rather important.
- chrismorgan 2y ago
  That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size). And let me tell you, your “Rust, Kotlin, Python, probably many more” don’t transpile to JS well. If you genuinely mean transpiling as distinct from compiling, I think you could even reasonably say that it’s simply not possible for many languages due to fundamental and incompatible differences. I’d count Rust as that due to things like resolution and aliasing. If you’re interested in targeting JavaScript, languages like this are your only reasonable alternative to JavaScript itself. (If you’re interested in targeting the web more generally, WebAssembly is a better target.)
  - smt88 2y ago
    I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.
    - chrismorgan 2y ago
      If you do mean more generically targeting the web, then I recommend avoiding the word “transpile”, which will be understood to be something far more restricted in scope.
    - akdev1l 2y ago
      Working with WASM isn’t really that good for interactive pages with dynamic DOM. If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard) It seems to me for most web applications JS is the only real alternative as of now
      - chrismorgan 2y ago
        > Working with WASM isn’t really that good for interactive pages with dynamic DOM. It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose. Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).
Myrmornis 2y ago
The motivation is giving people a chance to try these features and thus ultimately helping move the language in a good direction. That's what coffeescript did also.

smt88 2y ago

Languages like this don't make sense anymore. You can just pick a mature, feature-rich language you like (Rust, Kotlin, Python, probably many more) and transpile to JS.

Yahivin 2y ago
The GWT approach has its own downsides as well.
- smt88 2y ago
  A) GWT is 20 years old and not similar to how modern transpilation works B) What are the downsides?
  - Yahivin 2y ago
    The built in browser debugger is incredibly good. As long as the transpilation is simple and matches JS semantics you can still use the debugger. I haven't seen good debugging tools when using languages more distant from JS but I'd love to know if they've become viable.
    - smt88 2y ago
      You've been able to debug TypeScript (and anything else that transpiles to JS) natively in the browser for years using sourcemaps. That includes Dart, C#/F#, Go (as far as I know), and Python. For the languages that target wasm instead, there are different debugging stories. Kotlin's is very good, Rust's is pretty immature.
      - int_19h 2y ago
        Source maps are not sufficient to fully expose the semantics of the language being debugged to the debugger. You also need the expression evaluator (for stuff like Watch etc) to understand what it's debugging. And in cases where transpilation includes nontrivial mapping of data structures, you also need the ability to do that mapping in reverse to display the values. Source maps work great for TS because it is just "JavaScript with types" at this point.
bfung 2y ago
Or compile to wasm
troupo 2y ago
All those mature feature-rich languages started as "languages like this make no sense"
- chrismorgan 2y ago
  That’s certainly not true of Rust: Rust had a particular goal, easily recognised as worthwhile, which wasn’t possible with any existing languages. Everyone sensible agreed the language made a lot of sense, even if they weren’t sold on the practicality of its specific approach.
  - troupo 2y ago
    IIRC everyone was perplexed why Mozilla was spending time on what looked like a research/academic problem instead of focusing on Servo
    - chrismorgan 2y ago
      I didn’t get involved with any of this stuff until mid-2013, but at the very least by then, it was well understood that Servo couldn’t reach its potential without Rust.
      - troupo 2y ago
        Just to quote Wikipedia: > Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare, named after the group of fungi that are "over-engineered for survival". Mozilla began sponsoring the project in 2009, and would employ a dozen engineers to work on it full time over the next ten years So by 2013 it was already 7 years old. I very much doubt the original personal project was viewed as "a lot of sense" etc.
        chrismorgan 2y ago
        You’ll always easily find plenty of people that will say “that makes no sense”. But of people that worked in these sorts of fields, I imagine that, from the very start, there would have been significantly more than average approval for its goals, even if you wouldn’t expect it to succeed (such endeavours normally don’t). The niche Rust was targeting from the very beginning was one that was known to be underserved, and known to be rather important.
chrismorgan 2y ago
That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size). And let me tell you, your “Rust, Kotlin, Python, probably many more” don’t transpile to JS well. If you genuinely mean transpiling as distinct from compiling, I think you could even reasonably say that it’s simply not possible for many languages due to fundamental and incompatible differences. I’d count Rust as that due to things like resolution and aliasing. If you’re interested in targeting JavaScript, languages like this are your only reasonable alternative to JavaScript itself. (If you’re interested in targeting the web more generally, WebAssembly is a better target.)
- smt88 2y ago
  I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.
  - chrismorgan 2y ago
    If you do mean more generically targeting the web, then I recommend avoiding the word “transpile”, which will be understood to be something far more restricted in scope.
  - akdev1l 2y ago
    Working with WASM isn’t really that good for interactive pages with dynamic DOM. If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard) It seems to me for most web applications JS is the only real alternative as of now
    - chrismorgan 2y ago
      > Working with WASM isn’t really that good for interactive pages with dynamic DOM. It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose. Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).

Myrmornis 2y ago

The motivation is giving people a chance to try these features and thus ultimately helping move the language in a good direction. That's what coffeescript did also.