3 ms·

I will never understand why anyone would want to use a compiled language to do front-end development. The beauty of JS and especially the beauty of ClojureScri

by beders 5y ago

I will never understand why anyone would want to use a compiled language to do front-end development. The beauty of JS and especially the beauty of ClojureScript is that you can immediately see the effects of your work in an interactive environment. Using the right libraries you can have true hot reloading without destroying state giving you a terrific, fast, fluid development experience. What are acceptable compile and reload times for you guys loading WASM?

onei 5y ago
> ClojureScript is a compiler for Clojure that targets JavaScript. [1] If ClojureScript is compiled, why can't WASM be the same? [1] https://clojurescript.org/ https://clojurescript.org/
- CraigJPerry 5y ago
  In clojurescript you can press your slime or calva keystroke to send a form (or an expression from a rich comment) to the browser repl and see that immediately reflect and use the current state of the app without reloading. What’s the equiv workflow when compiling to wasm? Save file > compile > hot reload? > reconstruct state somehow? Is it like clojurescript where you interactively work on the app in the same way you might interactively craft a sql statement in a live db?
  - onei 5y ago
    In Rust, no clue because I've never tried. However, I did find a hot reload of WASM compiled from C++ [1]. If they're not equivalent, I would imagine it's a matter of ecosystem maturity rather than it being impossible. Realistically, hot reload is going to be something like inotify(7) hooked into a compiler and whatever it takes to reload seamlessly. If it's been solved in one general purpose language, it's likely to be possible in another. [1] https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot-reload.aspx?m=1 https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot...
    - CraigJPerry 5y ago
      You can definitely hot reload in rust: https://fasterthanli.me/articles/so-you-want-to-live-reload-rust https://fasterthanli.me/articles/so-you-want-to-live-reload-... (this person's blog is one of my fav's, i know that's a huge post but he covers everything really well). But this is missing the difference. When we say hot reload in javascript (or even better, hot module replacement) or java or rust or c++, there's usually annoying limitations like you can't change the arity of a function or you have to pause all the threads or you need some mechanism to reset state to a known good starting point because we just broke it (potentially). The difference with a lisp is that you don't need do any of that. You replace the function object in the system image (atomically) and you crack on like nothing happened. No waiting around, no rerunning state into the app. And you triggered it just from a keystroke in your editor. The developer experience is unparalleled.
ceocoder 5y ago
My rational for using something like this: I fully agree that toolchain you mentioned gives blazing fast initial devX, hot reload and everything. If that’s what you are optimizing for, it is a perfect solution. OTOH when you want to optimize for long term maintenance, growing codebase that is safe and easy to grow, easy to refactor, easy to check for odd things. I’d lean heavily on something compiled and with promise/guarantee of safety every time. In other words, it is all about trade offs and to each his own.
clusterfish 5y ago
Because dynamic typing is terrible for big projects, and typescript's fake sense of security doesn't cut it. When you know that your code works you don't need to check it in your browser every nanosecond (although you could).
- expliced 5y ago
  But typescript fake sense of security does cut it.
- gabereiser 5y ago
  You don’t need to check it in your browser at all if you wrote proper tests for it. TypeScript (with proper lint rules) is a huge win in my book compared to vanilla JS. That said, Rust’s compiler guarantees are best in class. The hot-reload, want to see it happen immediately, is great for quick prototypes but for large projects, nothing beats full coverage.
- danenania 5y ago
  Updating and checking over and over is usually more about getting the ux right than making it work or fixing bugs. A tight feedback loop makes a huge difference when you're iterating on look and feel. If you have to wait 10 seconds and fill out a form or two to restore the full app state after each change, it becomes a nightmare and you'll likely just give up on making a good ux. There are also lots of frontend bugs that aren't really bugs in the compiler sense, but just cause the user to see a slightly wrong or confusing thing for a given state. Tests can help, but for a UI with a lot going on, there are usually too many possible paths to write tests for them all, so doing a lot of QA as you go is hard to avoid. Typescript offers a pretty good balance here since you can turn off typechecking for live reloading and instead check types in the background or as part of the test suite.
zhiel 5y ago
You would never want to understand why this is better? Here is a couple of reasons: 1. It is backed up by a statically typed, safe, elegant language that is like a strict teacher that tells you to fuck off when you make a mistake... 2. HMR is possible with this... 3. Look, WASM is not fighting against you, it is fighting for you... anyone who is targeting JS and is forced to do so is welcome to choose any other language you want...

by beders 5y ago

onei 5y ago

> ClojureScript is a compiler for Clojure that targets JavaScript. [1] If ClojureScript is compiled, why can't WASM be the same? [1] https://clojurescript.org/ https://clojurescript.org/

CraigJPerry 5y ago
In clojurescript you can press your slime or calva keystroke to send a form (or an expression from a rich comment) to the browser repl and see that immediately reflect and use the current state of the app without reloading. What’s the equiv workflow when compiling to wasm? Save file > compile > hot reload? > reconstruct state somehow? Is it like clojurescript where you interactively work on the app in the same way you might interactively craft a sql statement in a live db?
- onei 5y ago
  In Rust, no clue because I've never tried. However, I did find a hot reload of WASM compiled from C++ [1]. If they're not equivalent, I would imagine it's a matter of ecosystem maturity rather than it being impossible. Realistically, hot reload is going to be something like inotify(7) hooked into a compiler and whatever it takes to reload seamlessly. If it's been solved in one general purpose language, it's likely to be possible in another. [1] https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot-reload.aspx?m=1 https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot...
  - CraigJPerry 5y ago
    You can definitely hot reload in rust: https://fasterthanli.me/articles/so-you-want-to-live-reload-rust https://fasterthanli.me/articles/so-you-want-to-live-reload-... (this person's blog is one of my fav's, i know that's a huge post but he covers everything really well). But this is missing the difference. When we say hot reload in javascript (or even better, hot module replacement) or java or rust or c++, there's usually annoying limitations like you can't change the arity of a function or you have to pause all the threads or you need some mechanism to reset state to a known good starting point because we just broke it (potentially). The difference with a lisp is that you don't need do any of that. You replace the function object in the system image (atomically) and you crack on like nothing happened. No waiting around, no rerunning state into the app. And you triggered it just from a keystroke in your editor. The developer experience is unparalleled.

ceocoder 5y ago

My rational for using something like this: I fully agree that toolchain you mentioned gives blazing fast initial devX, hot reload and everything. If that’s what you are optimizing for, it is a perfect solution. OTOH when you want to optimize for long term maintenance, growing codebase that is safe and easy to grow, easy to refactor, easy to check for odd things. I’d lean heavily on something compiled and with promise/guarantee of safety every time. In other words, it is all about trade offs and to each his own.

clusterfish 5y ago

Because dynamic typing is terrible for big projects, and typescript's fake sense of security doesn't cut it. When you know that your code works you don't need to check it in your browser every nanosecond (although you could).

expliced 5y ago
But typescript fake sense of security does cut it.
gabereiser 5y ago
You don’t need to check it in your browser at all if you wrote proper tests for it. TypeScript (with proper lint rules) is a huge win in my book compared to vanilla JS. That said, Rust’s compiler guarantees are best in class. The hot-reload, want to see it happen immediately, is great for quick prototypes but for large projects, nothing beats full coverage.
danenania 5y ago
Updating and checking over and over is usually more about getting the ux right than making it work or fixing bugs. A tight feedback loop makes a huge difference when you're iterating on look and feel. If you have to wait 10 seconds and fill out a form or two to restore the full app state after each change, it becomes a nightmare and you'll likely just give up on making a good ux. There are also lots of frontend bugs that aren't really bugs in the compiler sense, but just cause the user to see a slightly wrong or confusing thing for a given state. Tests can help, but for a UI with a lot going on, there are usually too many possible paths to write tests for them all, so doing a lot of QA as you go is hard to avoid. Typescript offers a pretty good balance here since you can turn off typechecking for live reloading and instead check types in the background or as part of the test suite.

zhiel 5y ago

You would never want to understand why this is better? Here is a couple of reasons: 1. It is backed up by a statically typed, safe, elegant language that is like a strict teacher that tells you to fuck off when you make a mistake... 2. HMR is possible with this... 3. Look, WASM is not fighting against you, it is fighting for you... anyone who is targeting JS and is forced to do so is welcome to choose any other language you want...