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

71–80 of 135 posts

Re: Scala.js no longer experimental

#71

Post by colin_jack »

stakent wrote: post #67
colin_jack wrote: post #41

Earlier quoted context omitted.

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/

Yeah I plan to ta, to be honest I like what I've seen/used of TypeScript too. However I'm thinking the big win will be in the longer term when JS picks up some of the ideas.

Re: Scala.js no longer experimental

#72

Post by adrusi »

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

I don't understand why compilers can't simply emit global variables containing structural descriptions of types. It seems like such a trivial thing to do. It would increase the size of the binary, but it would be possible to disable in projects that aren't using reflection, even automatically if the code never imports the reflection package.

Maybe someone can explain this.

Re: Scala.js no longer experimental

#73

Post by zanny »

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?

Why can't Python? Why can't Ruby? Why can't Perl?

Fundamentally, the languages able to run in the browser are only limited by what the browsers want to implement. It would be great if browsers could render QML, or could use or or whatever but that requires browsers to either depend on an external JVM or include on in the browser. Or you need to put the QML runtime in the browser or as a dependency. Or you have to put a Python interpreter in the browser or as a dependency.

Re: Scala.js no longer experimental

#74

Post by sjrd »

adrusi wrote: post #72
_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…

I don't understand why compilers can't simply emit global variables containing structural descriptions of types. It seems like such a trivial thing to do. It would increase the size of the binary, but it would be possible to disable in projects that aren't using reflection, even automatically if the code never imports the reflection package. Maybe someone can explain this.

Oh yes, compilers could do that. But because of the code explosion, everyone would actively stay away from that feature. And we, compiler writers, don't want to support a feature that's not used.

Re: Scala.js no longer experimental

#75

Post by sjrd »

euroclydon wrote: post #70
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?

No, it doesn't. Scala.js is a compiler that emits .js code from your .scala code. There is no layer between the JS VM and that .js code.

Re: Scala.js no longer experimental

#76

Post by Cyph0n »

jducoeur wrote: post #30
mercurial wrote: post #17

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

As mentioned upthread, hello world isn't really representative. A more useful metric is probably what I'm doing -- a large, complex single-page business app with lots of specialized gadgetry. Including the standard Scala.js prelude (100-200k), that currently clocks in at a bit under a megabyte. That's quite reasonable for a program of its complexity, and loads pretty fast. And once that is loaded and in the browser c…

Thanks for the perspective. It seems like a viable option for the frontend of my planned product, which I hope to write in Scala + Play.

Re: Scala.js no longer experimental

#77

Post by dragonwriter »

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 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.

Its more a case of not all the eggs being put in one basket. Google exploring many avenues to the same broad goal in parallel has been a widely observed phenomenon for a long time.

Re: Scala.js no longer experimental

#78

Post by eweise »

the_af wrote: post #66
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 v…

I program in Scala at work full time using Intellij and I'm having a great experience. No weird compilation errors, quick, responsive. Works almost as well as with Java files.

Re: Scala.js no longer experimental

#79

Post by sixbrx »

amelius wrote: post #44
icebraining wrote: post #32

Earlier quoted context omitted.

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

But you still can't use structurally shared data, which you need when you want to share large data-structures between threads.

If I understand you, I think it's a bit much to expect ScalaJS to somehow change the platform it is targeting, which is the browsers as accessed via Javascript (ie. without requiring plugins which would have made it DOA for most use cases). If browsers don't want threads that share data via Javascript control, and it appears they don't, and by design, then what is the alternative for ScalaJS? Same situation as with Javascript.

Re: Scala.js no longer experimental

#80

Post by icebraining »

lmm wrote: post #63
jbooth wrote: post #49

Earlier quoted context omitted.

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.

http://www-archive.mozilla.org/projects/blackwood/dom/
Post reply on HN