Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala.js 1.0.0-RC1

scala-js.org

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Scala.js 1.0.0-RC1

#31

Post by atc »

googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

> 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use.

... Just use Typescript.

Re: Scala.js 1.0.0-RC1

#33

Post by vips7L »

merb wrote: post #25
bad_user wrote: post #21

Earlier quoted context omitted.

> just not happy with the JVM memory reqs I'm curious if you did any measurements and what you prefer instead. The managed heap is very efficient. I have a web server (built in Scala) configured on my own VPS to run with a 10-100 MB heap. To this you add the JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead and I end up with a process using 190 MB (RES), which is reasonable for a server-side…

well compared to dotnet core 3 the java memory management is really really bad. in java memory is not more efficient than in node.js/php/ruby or python it's worse. what is better is the performance, especially when you have a lot of stuff on the heap the performance is predictable even with a memory size of > 16gb where the other languages lack of. GraalVM still misses a lot of stuff and is slower. so I think the big…

>GraalVM still misses a lot of stuff and is slower.

Are there benchmarks for this?

Re: Scala.js 1.0.0-RC1

#34

Post by vips7L »

googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

Why not scala native or substrateVM if you want lower memory requirements?

Re: Scala.js 1.0.0-RC1

#35

Post by virtualwhys »

vips7L wrote: post #34
googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

Why not scala native or substrateVM if you want lower memory requirements?

Scala Native [1] has been really quiet of late (last commit July 29), not sure what's going on. There was a lot of excitement when the project kicked off, hopefully it continues to evolve.

[1] https://github.com/scala-native/scala-native

Re: Scala.js 1.0.0-RC1

#36

Post by AzzieElbab »

Always been curious about workflow of people who use Scala.js. I am a complete newbie when it comes to frontend. How do you do frontendish interactive development considering scalac's slowness?

Re: Scala.js 1.0.0-RC1

#37

Post by gedy »

threeseed wrote: post #8

Would highly recommend pairing this with Slinky (React for Scala.js). https://slinky.dev

I'm disappointed that the (formerly?) built-in Scala XML handling could not be used for JSX vs these:

Slinky:

   div(
      h3("TODO"),
      TodoList(items = state.items),
      form(onSubmit := (handleSubmit(_)))(
        input(
          onChange := (handleChange(_)),
          value := state.text
        ),
        button(s"Add #${state.items.size + 1}")
      )
    )
scalajs-react:

Re: Scala.js 1.0.0-RC1

#38

Post by fnordsensei »

sjrd wrote: post #26
fnordsensei wrote: post #23

Earlier quoted context omitted.

ClojureScript ends up somewhere around the same size. Maybe it's some magic number that a full-featured environment converges to. Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.

There is a significant difference between CLJS and Scala.js regarding their use of GCC (Google Closure Compiler). In ClojureScript, GCC is a user-visible feature of the toolchain, so users are encouraged to use GCC-compatible libraries and the Closure Library in particular. In Scala.js, GCC is really an implementation detail of the toolchain, and its constraints are completely abstracted away from the user. This does…

I think the externs file maneuver might be outdated.

Admittedly, I'm using shadow-cljs as my go-to compiler (so I'm not sure what the state of vanilla is), but all I do is yarn add , and then require it in the file where I want to use it, and interact with it as if it were any other library.

Though it is true of shadow-cljs as well that it doesn't try to tree-shake external (non-CLJS/Closure) libs by default, though it will do it for project code and Clojure libraries.

Re: Scala.js 1.0.0-RC1

#39

Post by sjrd »

AzzieElbab wrote: post #36

Always been curious about workflow of people who use Scala.js. I am a complete newbie when it comes to frontend. How do you do frontendish interactive development considering scalac's slowness?

scalac is only slow when it needs to compile an entire project. But the Scala tooling ecosystem has invested a lot in incremental compilation, which means that most of the time when you make a change, only 1 or 2 files are recompiled, which is quite snappy. In turn, the Scala.js linker also performs its linking and optimizations incrementally, so that in an interactive development setting, the whole cycle is quite fast.
Post reply on HN