Live data from Hacker News

Scala.js no longer experimental

scala-lang.org

101–110 of 135 posts

Re: Scala.js no longer experimental

#101

Earlier quoted context omitted.

There was - it was called LiveConnect - but like most things to do with Java and the browser(s), it languished in a half-supported state, and really isn't worth thinking about any more. As are applets - a great idea, implemented poorly, and now essentially lost to the annals of history.

Don't forget about websites from academia that implement certain proof-of-concepts; for some reason that commumity still keeps using applets.

We used to do it because dealing with cross-browser compatibility was a pain. For instance, I used to use a 1-pixel applet instead of XMLHttpRequest for AJAX (slightly before they coined the term "AJAX") and applets for rendering live-updated XML-based diagrams (instead of SVG) in both cases because it simply made things less buggy and less of a pain to support at the time. But that was in 2004 to 2007.

But once we've written something, and it works, we're often a little slow updating it to newer tech, because we can't write a paper out of "the same thing I published earlier, but now using SVG and XHR instead of applets".

If it still just-about works, there's less impetus to rewrite it.

Re: Scala.js no longer experimental

#102
post #93
post #66

Earlier quoted context omitted.

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…

My experience with Scala IDE: - Yes, it's very slow. - Refactoring is limited, will sometimes refuse to happen, and will sometimes randomly move 1 character into the wrong place in the file. So yes it does "break", but not in a way that's hard to fix. - Variable inspection when debugging has always worked fine for me. - Scala-IDE never gives a "full" spurious compilation error (one that shows up in the problems tab a…

Thanks for the info. A couple of questions:

> - Variable inspection when debugging has always worked fine for me.

Are you using version 3 or 4? In version 3 this definitely didn't work, as stated in the changelog for version 4 ( http://scala-ide.org/docs/changelog.html, look for M3 "Show variable values in hovers when in suspended debug mode". It should be noted that for me, in version 3 selecting and watching a variable doesn't work either). This seems to be fixed in version 4, which was officially released on 2014-12-16.

> - Scala-IDE never gives a "full" spurious compilation error

True, this seems to be mostly a presentation issue, albeit a very distracting one. However, in my experience occasionally one of these errors will prevent the application from launching from Eclipse (for debugging, for example), which seems very odd.

In my experience, autocomplete sometimes stops working completely. Or maybe I'm really impatient :)

Re: Scala.js no longer experimental

#104

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…

There just are programmers who feel static typing is the only correct way to program. Google has always been in that camp (company wide directive, I suppose). Meanwhile, most of the internet runs on PHP.

I hope it will play out so that the statical types people can use something with statical types, and the dynamic types people can happily continue with their static types.

Re: Scala.js no longer experimental

#105
The "Hello World" example yields a 3500 LOC js file. I expected a high count but that still managed to shock me. Well, I'm still pretty excited about this announcement and looking forward to give it a try.

Re: Scala.js no longer experimental

#106

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…

There just are programmers who feel static typing is the only correct way to program. Google has always been in that camp (company wide directive, I suppose). Meanwhile, most of the internet runs on PHP. I hope it will play out so that the statical types people can use something with statical types, and the dynamic types people can happily continue with their static types.

(disclaimer: super ultra pro-static-types person)

I really wonder whether we won't get more conversion to static types. I think the popularity of dynamic typing languages is more due to the fact that static typing used to be a major pain. But with type inference being where it is, I think most languages can start moving to static typing without any costs to the users

The biggest representation of this is all the Pythonistas moving to Go. Well there's not that many, but the fact that Go "feels" like Python shows that maybe "fast and easy to use" is not as tightly coupled to "lack of typechecks" as we once thought

Re: Scala.js no longer experimental

#107
post #98

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…

I'm skeptical of any x-to-JS compiler as usually I end up debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want. On the other hand the Scala people know how to write compilers. We're live, in production, with Scala since 2011 and it's a joy: it actually delivers what's promised. Heard the same thing from Twitte…

> debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want.

Please forgive me for the accusation, but I've heard many people say this same statement to later found out they just meant "Well it's never happened to me... but it could... but it happened to this person I know...".

I personally can't think of many situations where you'd debug the machine generated javascript instead of using a sourcemap, can you give more detail on your experience?

Re: Scala.js no longer experimental

#108
post #98

Earlier quoted context omitted.

I'm skeptical of any x-to-JS compiler as usually I end up debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want. On the other hand the Scala people know how to write compilers. We're live, in production, with Scala since 2011 and it's a joy: it actually delivers what's promised. Heard the same thing from Twitte…

> debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want. Please forgive me for the accusation, but I've heard many people say this same statement to later found out they just meant "Well it's never happened to me... but it could... but it happened to this person I know...". I personally can't think of many situ…

To me this sounds like the same argument against C compilers: "You'll just end up debugging the generated asm anyway!".

Turns out (mature) compilers are generally better at writing code than humans, and most of the time you don't have to debug their code, only your own. Almost every time I've heard someone say "I found a bug in the compiler!", they didn't.

Re: Scala.js no longer experimental

#109
post #98

Earlier quoted context omitted.

I'm skeptical of any x-to-JS compiler as usually I end up debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want. On the other hand the Scala people know how to write compilers. We're live, in production, with Scala since 2011 and it's a joy: it actually delivers what's promised. Heard the same thing from Twitte…

> debugging 2 different codes, where the second one is machine generated. After that you try to work around on the first to make the generated one do what you want. Please forgive me for the accusation, but I've heard many people say this same statement to later found out they just meant "Well it's never happened to me... but it could... but it happened to this person I know...". I personally can't think of many situ…

At least for CoffeeScript, the generated code is so close to the the original source that the mapping is obvious. I've never needed to get the source map working.

Re: Scala.js no longer experimental

#110
post #36

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.

It's more that the left hand doesn't need permission from the right hand's boss to develop a competing tool.
Post reply on HN