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

Scala.js no longer experimental

scala-lang.org

Post reply on HN
Print view View original

31–40 of 135 posts

Re: Scala.js no longer experimental

#31

Post by adrusi »

joajoa wrote: post #13

I know it's a shameless plug, but if you want to convert any Java bytecode with less semantic differences than scala.js and full reflection support you might want to give https://www.defrac.com/ a try.

Not really the same thing, scalajs is supposedly has full compatibility with Scala, but it doesn't try to go beyond that. Its embracing JavaScript as a platform.

100% code reuse across all platforms is unachievable. What a lot of do today is complete horseshit relative to the state of the art, but different platforms have different ui conventions and following their rules can't be abstracted away into some library, obeying these conventions requires some intuition about human psychology.

By embracing the JavaScript platform, the scalajs folks are leaving the playing field open as to how to deal with multiple platforms. Maybe we can hook up scalajs to react and react native, there seems to be a bit of hype around that.

Re: Scala.js no longer experimental

#32

Post by icebraining »

amelius wrote: post #28
bad_user wrote: post #25

Earlier quoted context omitted.

You don't run code in multiple threads, but Scala's ExecutionContext is not about threads, but about asynchronous execution and JS is fine with that. Also, all of Scala's collections, including the persistent ones are supported.

This (asynchronous execution) means we are forced to use cooperative multitasking, which is probably not good for reduced latency, and therefore bad for responsiveness (compare to the Windows 3.11 days where we were forced to use cooperative multitasking). Yes, I know most JS programs today use asynchronous execution successfully in practice, but to use it as the basis of a language platform is not a good idea IMHO.…

You can actually have multithreading by running Scala actors in web workers: https://github.com/sjrd/scala-js-actors

Re: Scala.js no longer experimental

#34

Post by smandou »

mercurial wrote: post #17

I'm curious to know the size of a scala.js hello world program.

Traceur (ES6 compiler) itself has a runtime of several hundreds kb. Nothing you can't avoid at some point. There is an overhead for sure. But in most cases, execution time is spent in native calls (Dom rendering especially).

Re: Scala.js no longer experimental

#35

Post by julius »

This sounds great. I have not really used Scala before. 3 questions:

- How good do IDEs understand Scala these days? Compared to C#/Java, where IDEs instantly know a crazy lot about your code. I am looking at features like IntelliSense, marking wrong code, marking typos, marking unused code, telling me about unhandled Exceptions etc.

- Is there any difference, on the IDE side, between Scala support and Scala.JS support?

- Is a development cycle possible, where I save and I can instantly reload the page in my browser to see the differences?

- (Bonus Question) How well does it integrate with React. If my memory is not fooling me, Scala supports something like Inline-XML. Can I write React-Code, like I write JSX code with it? Any examples?

Re: Scala.js no longer experimental

#36

Post by desdiv »

noelwelsh wrote: post #26

I was very sceptical of Scala.js, but decided to use it in a low risk project ( http://github.com/underscoreio/doodle ) to render to the HTML canvas and I am shocked at how well it works. The community is moving very quickly as well, and many advanced Scala projects have had the necessary tweaks applied to run in Scala.js. Looking at broader trends, there is a clear movement towards static typing on the Javascript VM…

Google is developing SoundScript

Aren't they doing Dart as well? That has optional typing. Plus they have GWT, which is Java to JS.

Don't get me wrong, I'm super grateful to receive their fruits of labor for free, but this looks like a case of the left hand not knowing what the right hand is doing.

Re: Scala.js no longer experimental

#37

Post by sjrd »

julius wrote: post #35

This sounds great. I have not really used Scala before. 3 questions: - How good do IDEs understand Scala these days? Compared to C#/Java, where IDEs instantly know a crazy lot about your code. I am looking at features like IntelliSense, marking wrong code, marking typos, marking unused code, telling me about unhandled Exceptions etc. - Is there any difference, on the IDE side, between Scala support and Scala.JS suppo…

- IDEs for Scala are pretty good, nowadays. They do all of what you mentioned (except unhandled exceptions, because that's a Java-specific thing).

- There's no difference between Scala and Scala.js support. To your IDE, Scala.js is Just Scala.

- There is a development cycle, absolutely, and it's pretty fast! With Workbench (https://github.com/lihaoyi/workbench) you don't even need to reload the page: it does so automatically!

- For React, there is essentially scalajs-react (https://github.com/japgolly/scalajs-react). It does not support inline-XML per se, because it relies more on ScalaTags instead (https://github.com/lihaoyi/scalatags), but at some point there was a proof of concept showing it was possible to implement with macros.

Re: Scala.js no longer experimental

#38

Post by sjrd »

tootie wrote: post #33
heathermiller wrote: post #3

Or, said another way, Scala now officially runs on both the JVM and in the browser.

Am I correct in my inference that Scala in the browser cannot import Java classes? Meaning this isn't some backdoor to a Java-to-JavaScript compiler?

You are correct. Scala.js compiles Scala code to JS, not bytecode. A number of core Java classes have been ported to Scala.js so they can be used anyway, though. (see http://lihaoyi.github.io/hands-on-scala-js/#JavaAPIs for a mostly exhaustive list so far)

Re: Scala.js no longer experimental

#39

Post by caente »

julius wrote: post #35

This sounds great. I have not really used Scala before. 3 questions: - How good do IDEs understand Scala these days? Compared to C#/Java, where IDEs instantly know a crazy lot about your code. I am looking at features like IntelliSense, marking wrong code, marking typos, marking unused code, telling me about unhandled Exceptions etc. - Is there any difference, on the IDE side, between Scala support and Scala.JS suppo…

- How good do IDEs understand Scala these days? Compared to C#/Java, where IDEs instantly know a crazy lot about your code. I am looking at features like IntelliSense, marking wrong code, marking typos, marking unused code, telling me about unhandled Exceptions etc.

IntellIj has a very nice plug-in, it will tell you a lot about your code, including suggestions of best practices. The down side is that the more "functional" your code gets, the slower IDE becomes(that's also true for Eclipse), but chances are that when that happens, you won't care about having an IDE. So IntellIj will be great to get you started, it does help a LOT.

Is there any difference, on the IDE side, between Scala support and Scala.JS support?

Not sure about this, it seems like you can just code in IntelliJ/Eclipse, but the debugging has to happen in the browser, it does work very nicely(you debug the scala code, not the generated javascript)

I owe you the bonus question :-P

Re: Scala.js no longer experimental

#40

Post by DomBlack »

desdiv wrote: post #36
noelwelsh wrote: post #26

I was very sceptical of Scala.js, but decided to use it in a low risk project ( http://github.com/underscoreio/doodle ) to render to the HTML canvas and I am shocked at how well it works. The community is moving very quickly as well, and many advanced Scala projects have had the necessary tweaks applied to run in Scala.js. Looking at broader trends, there is a clear movement towards static typing on the Javascript VM…

Google is developing SoundScript Aren't they doing Dart as well? That has optional typing. Plus they have GWT, which is Java to JS. Don't get me wrong, I'm super grateful to receive their fruits of labor for free, but this looks like a case of the left hand not knowing what the right hand is doing.

Don't forget the Google Closure compiler in advance mode.
Post reply on HN