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

41–50 of 59 posts

Re: Scala.js 1.0.0-RC1

#41

Post by sjrd »

gedy wrote: post #37
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:

If you're into JSX, then probably Bindings.scala is a better fit for you:

https://github.com/ThoughtWorksInc/Binding.scala#step-3-crea...

Re: Scala.js 1.0.0-RC1

#42

Post by sjrd »

gedy wrote: post #40

I can't speak for everyone, but while I loved programming in Scala, I can't stand sbt[0] as a build tool. If I could use Scala.js without all this (e.g. Webpack or Rollup) could see myself using. [0] https://www.scala-sbt.org

sbt is not the only build tool that supports Scala.js. I at least know of support for Maven [1], Pants [2], Gradle [3] (a bit outdated that one, but an interested person could revive it), and there seems to be a path forward for Bazel [4].

That said, I would like to see a Webpack plugin for Scala.js as well.

[1] https://github.com/random-maven/scalor-maven-plugin [2] https://github.com/pantsbuild/pants/tree/master/contrib/scal... [3] https://github.com/gtache/scalajs-gradle [4]

Re: Scala.js 1.0.0-RC1

#43

Post by vips7L »

virtualwhys wrote: post #35
vips7L wrote: post #34

Earlier quoted context omitted.

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

Yeah I figured that was the case. There is a lot of steam behind native-image with graal/substrate though.

Re: Scala.js 1.0.0-RC1

#44

Post by AzzieElbab »

sjrd wrote: post #39
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 fa…

fine, but what tooling/workflow would one use for the type of development javascripters are accustomed to? Like make a change and immediately observe result on the page?

Re: Scala.js 1.0.0-RC1

#45

Post by sjrd »

AzzieElbab wrote: post #44
sjrd wrote: post #39

Earlier quoted context omitted.

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 fa…

fine, but what tooling/workflow would one use for the type of development javascripters are accustomed to? Like make a change and immediately observe result on the page?

Workbench [1], for example :)

[1] https://github.com/lihaoyi/workbench

Re: Scala.js 1.0.0-RC1

#46

Post by Nullabillity »

spir wrote: post #28
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…

I recently learned that Scala.js doesn't yet support generating TypeScript *.d.ts type definitions. I intend to open a Gitcoin bounty to get this work done. Have you had any success using Scala.js-generated JavaScript in TypeScript projects? I'm quite interested in a full stack of create-react-app + TypeScript + graphQL + front end libraries written in Scala + back end services written in Scala.

In general I'd advise against using Scala.js for libraries. The Scala.js runtime is pretty heavy, and Scala's and TypeScript's type systems are different enough that it tends to be difficult to design an API that feels native in both.

Have you considered ScalaJS-React[0] or Outwatch[1] instead?

[0]: https://github.com/japgolly/scalajs-react

[1]: https://outwatch.github.io/?lang=scala

Re: Scala.js 1.0.0-RC1

#47

Post by AzzieElbab »

sjrd wrote: post #45
AzzieElbab wrote: post #44

Earlier quoted context omitted.

fine, but what tooling/workflow would one use for the type of development javascripters are accustomed to? Like make a change and immediately observe result on the page?

Workbench [1], for example :) [1] https://github.com/lihaoyi/workbench

Thank you. Did not know about this plugin

Re: Scala.js 1.0.0-RC1

#48

Post by jdc »

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…

> well compared to dotnet core 3 the java memory management is really really bad.

Can you be more specific? What kind of workload and which JVM are you talking about?

Re: Scala.js 1.0.0-RC1

#49

Post by gedy »

sjrd wrote: post #41
gedy wrote: post #37

Earlier quoted context omitted.

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:

If you're into JSX, then probably Bindings.scala is a better fit for you: https://github.com/ThoughtWorksInc/Binding.scala#step-3-crea...

Looks awesome, thank you!

Re: Scala.js 1.0.0-RC1

#50

Post by apta »

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…

> has dropped Scala on the backend

What did you replace it with out of curiosity?

Post reply on HN