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.
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?
"Java was originally designed for interactive television, but it was too advanced for the digital cable television industry at the time."
Likely it was designed, and then used for their first product. Then when that failed, they kept the language for other possible targets.
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.
Awesome. My own experience is more with Scala IDE, which is terrible. I tried IntelliJ for a brief time last year, saw it had spurious compilation errors, and the gurus at my office told me it was even worse than Scala IDE (but you know how gurus are...).
Out of curiosity:
- Do you have incremental compilation enabled with IntelliJ?
- Do you ever experience a compile error in the IDE for code that SBT is able to compile successfully?
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.
You've hit the nail on the head with left-hand-right-handedness at Google. Every interaction I've had with that company reveals behavior reflective of this condition. You've gotta scratch the surface to find it, but lately it's not very deep. When I interview places, and the interviewer gives me a single question, I hit them with something almost no one expects ("If you could change one thing without veto, what would it be?"). When I interviewed there at Google some time ago (I turned down their offer because of the answers I got to this question), six out of the seven interviewers I asked replied with some variation on "All the low-hanging fruit has been picked, and most people aren't in a position to solve the gnarly problems, so I wish I could do work that challenges me." This immediately sent up red flags with me, along with the weird sense of hivemind I got at the Googleplex. It wasn't exactly like wandering around a Borg cube, but it was close. Then recently the company I work for has had visitors from Google, and while I'm not involved in the interactions personally, there's a huge sense of this left-hand-right-hand problem even among teams working on the same product, just different groups. This is probably the case with all large corporations after a certain critical mass, but I'm personally experiencing a selection bias for Google in particular.
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.
Awesome. My own experience is more with Scala IDE, which is terrible. I tried IntelliJ for a brief time last year, saw it had spurious compilation errors, and the gurus at my office told me it was even worse than Scala IDE (but you know how gurus are...). Out of curiosity: - Do you have incremental compilation enabled with IntelliJ? - Do you ever experience a compile error in the IDE for code that SBT is able to comp…
Our codebase is a few years old so we are using maven for our builds instead of SBT. I've been using the intellij incremental compiler and it seems to work well. Once in a while it will complain so I hit the reimport button on maven and then its fine. There is no code in our codebase that maven compiles but Intellij can't. I do remember using spray.io and Intellij had a hard time with that library but recently the problem has gone away.
Looks like I'm gonna have to ditch React and IO now. I think those are getting outdated. Will be rewriting all apps in Scala.js.
With the JVM of the near future [0] running JavaScript natively, that could change again. Long before you know it, you'd be running java-scala-clojure-javascript code inside of the same jvm on the server, and on the client...
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.…
But this applies to any javascript program (or compiled to javascript). If you have specific requirements then scala.js is not the tool. Scala is.
If you care about the learning curve: Take a look at https://github.com/sinelaw/inferno It aims to add a type system to a subset of Javascript. It's not quite ready yet, but it already shows quite some promise. There's also Flow and Google's Closure/et-al, but they are more lenient and accept more valid and invalid programs.
If I just want types+js, Typescript is already pretty mature and widely supported (e.g. good integration with node, support for lots of popular libraries via DefinitelyTyped). What does this inferno offer over that?
According to the author of Inferno, TypeScript copies all the "bugs" and error-prone behaviors of JS, and is also a superset, not a subset. Inferno being a subset lets you use all your JS tooling directly with Inferno code.