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

61–70 of 135 posts

Re: Scala.js no longer experimental

#61

Post by densh »

_ea1k wrote: post #55

I understand why these types of compilers lack reflection support, but it still bothers me (and general makes me want to avoid them). JavaScript is naturally a very dynamic environment, and both Java and Scala have some pretty strong dynamic capabilities of their own. But somehow when they are combined (GWT or Scala.js) you end up with something that is more static than Java or JavaScript. I know the reasons have to…

In Scala one can perform reflection purely at compile-time using macros [1]. This lets you to generate code that would have required reflection in other languages with a much better performance. For example pickling [2] library uses macros to statically generate highly efficient serialisation and deserialisation boilerplate.

[1] http://docs.scala-lang.org/overviews/macros/overview.html

[2] http://lampwww.epfl.ch/~hmiller/pickling/

Re: Scala.js no longer experimental

#63

Post by lmm »

jbooth wrote: post #49
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…

So here's my question, how come no browser has a way for a java applet to manipulate the DOM? We've got GWT compiling java to JS, we've got this compiling scala to JS.. and the JVM was originally built to run inside of a browser. Why can't we just close the circle? I guess people don't want their website visitors to see a "you must upgrade java" popup first thing?

My guess is that Mozilla would never support it.

Re: Scala.js no longer experimental

#65

Post by nowxue »

noelwelsh wrote: post #59
_ea1k wrote: post #55

I understand why these types of compilers lack reflection support, but it still bothers me (and general makes me want to avoid them). JavaScript is naturally a very dynamic environment, and both Java and Scala have some pretty strong dynamic capabilities of their own. But somehow when they are combined (GWT or Scala.js) you end up with something that is more static than Java or JavaScript. I know the reasons have to…

Reflection is very much the last option when using Scala, as it breaks the ability to statically reason about code.

Yes, I agree. Although using macros is not as easy.

Re: Scala.js no longer experimental

#66

Post by the_af »

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…

Let me contradict the other answers with my personal experience: the two IDEs for Scala I know, Scala-IDE (Eclipse based) and IntelliJ are relatively bad.

- They are very slow.

- They have poor refactoring support (Scala-IDE's support is still marked as experimental; all but the simplest refactoring will often randomly break code, either by not doing a full refactor, or by introducing gibberish).

- Until the latest version of Scala-IDE, you couldn't inspect variable contents while debugging. I can confirm the latest version does let you inspect variables, but I'm not sure how stable this is.

- This is the killer disadvantage for me: both Scala-IDE and IntelliJ give spurious compilation errors pretty often, even for relatively trivial code. I know there are valid technical reasons why this isn't solved yet, but to me it's unacceptable that an IDE for a statically typed language gives spurious compilation errors: after all, compile-time errors are the main tool a statically typed language gives us. It's the one feature that absolutely must work correctly.

- Even trivial autocomplete randomly stops working for Scala-IDE. This may be related to the spurious compilation errors.

I've been told the unofficial recommendation from the Scala community is to disable incremental compilation in the IDE and compile with SBT. Consider what this says about the maturity of current IDEs.

Re: Scala.js no longer experimental

#67

Post by stakent »

colin_jack wrote: post #41
mercurial wrote: post #16

Earlier quoted context omitted.

> Plus JQuery - I don't see a point in doing it the Scala way when JQuery and other libraries are just as efficent and I will likely use them anyway. I won't speak about Scala in particular, but using a statically typed language with a strong type system is much more about safety than about "efficiency" (whatever this means). Javascript is brittle, and the idea of doing any kind of refactoring on a large JS codebase…

I actually don't think its so much about code safety either. To me the real top advantage of static typing is that it leaves the code self-documenting, easier to navigate around, easier to refactor as you say...etc. Having said that the flexibility JS gives you is huge, I've played with Scala and its at the opposite end of the scale. I don't mind that but I am more interested in things like gradual typing being added…

Try Facebook's flow.

http://flowtype.org/

Re: Scala.js no longer experimental

#68

Post by mjt0229 »

jbooth wrote: post #49
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…

So here's my question, how come no browser has a way for a java applet to manipulate the DOM? We've got GWT compiling java to JS, we've got this compiling scala to JS.. and the JVM was originally built to run inside of a browser. Why can't we just close the circle? I guess people don't want their website visitors to see a "you must upgrade java" popup first thing?

Wasn't the JVM originally built to run inside of a toaster?

Re: Scala.js no longer experimental

#69

Post by sjrd »

wampler wrote: post #62

Is Scala.js recommended for small apps? Say something like Hello World?

It's not unrecommended, but it's definitely not where it shines most. It's difficult to get below the 100 KB not gzipped size. Although if you use jQuery in your JS hello world, you also gather up 33 KB just for jQuery, so it's still the same order of magnitude.

Re: Scala.js no longer experimental

#70

Post by euroclydon »

apo wrote: post #56

Let's say I want to use Scala.js to build, not an application, but a JavaScript library. The library exposes a JavaScript API that JavaScript code can call. The library's objects can be used in full from JavaScript. Can I do this with Scala.js? If so, how? Very few, if no, *-to-JavaScript cross-compilers can do this. For example, Dart might seem to be that language, but on closer inspection, it's not. Your library is…

Are you saying that Scala.js ships with a Scala VM in JS, like EMScripten?
Post reply on HN