4 ms·

I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compi

I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?

Vinnl 9y ago
Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.
- randomsearch 9y ago
  TypeScript has previously been recommended, so I will take a look. I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
  - fulafel 9y ago
    WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.
    - naasking 9y ago
      > WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. How come?
      - machiaweliczny 9y ago
        It's too simple to support dynamic language features AFAIK.
        naasking 9y ago
        So are machine instructions. It wouldn't be any harder to build a dynamic language runtime on web assembly than for regular assembly.
- fulafel 9y ago
  I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.
  - Vinnl 9y ago
    If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.
    - grzm 9y ago
      There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used. I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.
      - Vinnl 9y ago
        Yeah I mean, many compile-to-JS languages have pretty good ecosystems (I know Elm is one, and I believe you that ClojureScript is too), but it's always going to be a pain in the ass at some point. Hell, I've been wrestling with just setting up Jest with TypeScript not that long ago, and measuring code coverage still isn't perfect. You're not going to tell me that you never run into those sort of things with non-JS languages that compile to JS.
innocentoldguy 9y ago
I use Elm for all my front-end work. Its compiler and debugging tools are really nice. I also like its functional nature. Elm helps eliminate most of the common issues with JS code and I can also accomplish the same thing with a lot less code in Elm. It's probably not for everyone, but I like it.

Vinnl 9y ago

Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.

randomsearch 9y ago
TypeScript has previously been recommended, so I will take a look. I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
- fulafel 9y ago
  WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.
  - naasking 9y ago
    > WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. How come?
    - machiaweliczny 9y ago
      It's too simple to support dynamic language features AFAIK.
      - naasking 9y ago
        So are machine instructions. It wouldn't be any harder to build a dynamic language runtime on web assembly than for regular assembly.
fulafel 9y ago
I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.
- Vinnl 9y ago
  If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.
  - grzm 9y ago
    There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used. I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.
    - Vinnl 9y ago
      Yeah I mean, many compile-to-JS languages have pretty good ecosystems (I know Elm is one, and I believe you that ClojureScript is too), but it's always going to be a pain in the ass at some point. Hell, I've been wrestling with just setting up Jest with TypeScript not that long ago, and measuring code coverage still isn't perfect. You're not going to tell me that you never run into those sort of things with non-JS languages that compile to JS.

innocentoldguy 9y ago

I use Elm for all my front-end work. Its compiler and debugging tools are really nice. I also like its functional nature. Elm helps eliminate most of the common issues with JS code and I can also accomplish the same thing with a lot less code in Elm. It's probably not for everyone, but I like it.