Scala.js no longer experimental(scala-lang.org)
scala-lang.org
Scala.js no longer experimental
http://scala-lang.org/news/2015/02/05/scala-js-no-longer-experimental.html
134 comments
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 Twitter, LinkedIn and Netflix too.
So maybe it worth a try; especially if it will integrate with ReactJs / React Native. Sounds like a match made in heaven.
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 Twitter, LinkedIn and Netflix too.
So maybe it worth a try; especially if it will integrate with ReactJs / React Native. Sounds like a match made in heaven.
> 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?
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?
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.
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.
I've found 3 compiler bugs during my 15 years as professional developer.
One was a optimizer bug sprintf in a for loop reset the ecx register so the loop became infinite and the last two where valid code that crashed the compiler (how do I know that, because the crashes dissappeared with small modifications of the code, like newlines). But yeah they are pretty rare.
One was a optimizer bug sprintf in a for loop reset the ecx register so the loop became infinite and the last two where valid code that crashed the compiler (how do I know that, because the crashes dissappeared with small modifications of the code, like newlines). But yeah they are pretty rare.
Depends if you're trying to debug optimized code or not... sometimes I try to do that since I'm too impatient to recompile something at -O0. Sometimes it works, sometimes I end up wasting more time than the recompilation would have taken.
I've had this happen with Clojurescript. If I recall correctly, runtime errors refer to the generated code, rather than to the source. So it can be hard to diagnose what exactly is going wrong.
This may have changed since I was last working with Clojurescript.
This may have changed since I was last working with Clojurescript.
There's a difference between a lightweight transpiler like JSX and a compiler.
ClojureScript is pretty lightweight, but GWT and Scala.js compile process is not an easy one. Even Bootstrap.js optimization with Google Closure Compiler is an uphill battle. Try it with --compilation_level ADVANCED_OPTIMIZATIONS
Sourcemap does not help much with compiler bugs or if the compiler people have different opinion from you on how something should be translated.
ClojureScript is pretty lightweight, but GWT and Scala.js compile process is not an easy one. Even Bootstrap.js optimization with Google Closure Compiler is an uphill battle. Try it with --compilation_level ADVANCED_OPTIMIZATIONS
Sourcemap does not help much with compiler bugs or if the compiler people have different opinion from you on how something should be translated.
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.
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.
I can't speak to any other x-to-JS transpiler but I've been writing ClojureScript almost every day for close to two years and this has never been an issue. At the very least this has to be dependent on which 'x' we're talking about.
I can't speak to any other x-to-JS transpiler but I've been writing ClojureScript almost every day for close to two years and this has never been an issue. At the very least this has to be dependent on which 'x' we're talking about.
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?
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.
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.
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.
There are quite a few applets demonstrating chemical reactions/bonds or physical equations etc., and as such applets are relatively common in teaching materials for high school (/secondary education) physics and chemistry, at least with teachers (I had or) I have substituted.
They are obviously years old and rarely signed, which is a shame because quite often there are plenty of demos, none of which I can run with modern default settings of a PC (and sometimes I wouldn't have enough credentials to do anything about it, anyway).
They are obviously years old and rarely signed, which is a shame because quite often there are plenty of demos, none of which I can run with modern default settings of a PC (and sometimes I wouldn't have enough credentials to do anything about it, anyway).
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 <script type="text/python"> or <script type="text/scala"> 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.
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 <script type="text/python"> or <script type="text/scala"> 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.
None of those languages have a secure sandbox and writing one is incredibly difficult, even for a language designed to run in such an environment (Java). Native Client might be interesting here to build sandboxes for other languages.
Lua was made with embedding in mind. You can start a VM with an empty global environment (no standard libraries etc..) but there is not a big benefit in jumping from js to lua because they are so similar.
The old Netscape Java Applet APIs supported dom manipulation:
http://www.java2s.com/Code/JavaScript/Development/UsingJavaS...
I believe that other browsers that supported applets supported these APIs as well.
I don't think that anyone really wants to bring back Java Applets, though.
http://www.java2s.com/Code/JavaScript/Development/UsingJavaS...
I believe that other browsers that supported applets supported these APIs as well.
I don't think that anyone really wants to bring back Java Applets, though.
[deleted]
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.
http://www.oracle.com/technetwork/java/javase/overview/javah...
Likely it was designed, and then used for their first product. Then when that failed, they kept the language for other possible targets.
http://www.oracle.com/technetwork/java/javase/overview/javah...
My guess is that Mozilla would never support it.
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.
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.
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?")
I will remember this one. That's a great question for interviews.
I will remember this one. That's a great question for interviews.
Even from the POV of the interviewer it's a great question. I'd give my answer then brainstorm with the interviewee about how they would propose solving that problem.
Would you feel comfortable asking an interviewee the same question about their last job? It could give a sense of how they think / why they are looking for a new spot but might be a little invasive.
Would you feel comfortable asking an interviewee the same question about their last job? It could give a sense of how they think / why they are looking for a new spot but might be a little invasive.
Also AtScript, for the upcoming Angular 2.0: https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...
"Google’s product strategy: Make two of everything" http://arstechnica.com/business/2014/10/googles-product-stra...
Not a bad thing to let two or more projects compete to encourage innovation, than granting each team exclusive privilege to represent the whole company in the area.
Not a bad thing to let two or more projects compete to encourage innovation, than granting each team exclusive privilege to represent the whole company in the area.
I think this is fairly typical of large companies. For example, Facebook also has a framework called Javelin that predates React by a few years and had it's own take on functional reactive programming. It's best to think of a large company as several small companies pursuing their own agendas.
> 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.
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.
It's more that the left hand doesn't need permission from the right hand's boss to develop a competing tool.
Don't forget the Google Closure compiler in advance mode.
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.
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
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
I've learned Go by doing a MOOC on discrete optimization. Mostly, it was fine and fun. But eventually I switched back to JavaScript out of frustration because some things were simply too complicated.
Just look at the sorting library of Go. I don't think they have solved the problem of static types in a satisfactory way.
Just look at the sorting library of Go. I don't think they have solved the problem of static types in a satisfactory way.
What makes you say "with type inference being where it is"?
Have there been recent advancements?
This is personal impression, but there haven't really been any advances in research per se, but there's been a lot of advances in tooling.
Now having type inference is an "expected" feature of most languages, now that there's a good amount of institutional knowledge. Along with first-class functions and the like. These are old things but it takes a while to propagate
Now having type inference is an "expected" feature of most languages, now that there's a good amount of institutional knowledge. Along with first-class functions and the like. These are old things but it takes a while to propagate
That's funny, I'm currently writing a Canvas visualization, the code base is getting bigger than anticipated, hence messier than I'd like. When I saw this article I thought "damn, I bet this would be way easier managed in Scala, if I only knew Scala".
If you want to learn Scala allow me to make a shameless plug:
- We are using Doodle as the tool for exploring Scala in free events running in San Francisco and Edinburgh in March. More will be scheduled later.
- We are using the design of Doodle as a case study in our online Essential Scala course. This is a paid course, with the first iteration starting in late Feb at a crazy 50% discount (75% off for diversity applicants).
All our events are listed on http://underscore.io/events/
- We are using Doodle as the tool for exploring Scala in free events running in San Francisco and Edinburgh in March. More will be scheduled later.
- We are using the design of Doodle as a case study in our online Essential Scala course. This is a paid course, with the first iteration starting in late Feb at a crazy 50% discount (75% off for diversity applicants).
All our events are listed on http://underscore.io/events/
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 locked inside a JavaScript VM-like data structure.
Although you can get a JavaScript object out of Dart-to-JavaScript compiled library, you need to manually hook up every function in its API yourself. In other words, it's not practical to use Dart to build a JavaScript library that exposes a sophisticated JavaScript API.
Is this possible in Scala.js?
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 locked inside a JavaScript VM-like data structure.
Although you can get a JavaScript object out of Dart-to-JavaScript compiled library, you need to manually hook up every function in its API yourself. In other words, it's not practical to use Dart to build a JavaScript library that exposes a sophisticated JavaScript API.
Is this possible in Scala.js?
Yes, this is possible.
http://www.scala-js.org/doc/export-to-javascript.html
http://www.scala-js.org/doc/export-to-javascript.html
Exactly what I was looking for, thanks!
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.
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 do with the static compilation optimization, but I still think this is a huge downside relative to languages that are designed for the browser from the start.
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 do with the static compilation optimization, but I still think this is a huge downside relative to languages that are designed for the browser from the start.
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/
[1] http://docs.scala-lang.org/overviews/macros/overview.html
[2] http://lampwww.epfl.ch/~hmiller/pickling/
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.
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.
Ceylon does this when compiling to JS because it has to support reified generics both on the jvm and in the browser. I don't like the size of the model though. It's huge.
That's exciting. I have worked extensively with Scala during my Master's project. What I'd really like to know is what this means in the context of the current trend of JavaScript (both client and server-side).
I'm currently working exclusively on MeteorJS, Node.JS and Angular and fail to see the relevance other than porting Scala applications to the web and making Web App development easier for developers familiar with Scala. However, without the kind of structure and inherent capabilities that a MeteorJS or DerbyJS offers, what's the USP here?
I'm currently working exclusively on MeteorJS, Node.JS and Angular and fail to see the relevance other than porting Scala applications to the web and making Web App development easier for developers familiar with Scala. However, without the kind of structure and inherent capabilities that a MeteorJS or DerbyJS offers, what's the USP here?
Scala.js, Clojure.js etc. treat JavaScript as assembly language and the browser as a target architecture. It's not about porting applications. It is about accessing the same data structures and abstractions on both ends of the wire when writing code.
For languages like Scala this means things as obvious as keeping class based inheritance with traits when writing client code for the browser. Those classes can share the same hierarchy with the server side.
This means that the decisions about where to execute a feature becomes less likely to be driven by differences between client and server language features. The effort can be put into determining which execution environment better solves the problem.
For languages like Scala this means things as obvious as keeping class based inheritance with traits when writing client code for the browser. Those classes can share the same hierarchy with the server side.
This means that the decisions about where to execute a feature becomes less likely to be driven by differences between client and server language features. The effort can be put into determining which execution environment better solves the problem.
You can still use all of your favourite JS libraries in Scala similarly to how one can can use Java libraries on JVM.
http://www.scala-js.org/doc/calling-javascript.html
http://www.scala-js.org/doc/calling-javascript.html
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?
- 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?
- 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.
- 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.
You have an alternative with a more closer syntax to the original one.
https://github.com/xored/scala-js-react
https://github.com/xored/scala-js-react
- 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
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
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.
- 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.
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?
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?
IntelliJ's Scala support has improved leaps and bounds the past 6 months. I'd give it another try if you have the opportunity.
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.
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 and with a full icon on the left) - or rather, no more than Eclipse in Java does (the kind where you have to refresh / clean the project do sometimes happen). On some constructs it will show a spurious "presentation" compiler error (red underline, simpler icon on the left), but it's easy to visually tell the two apart. I never think code is broken when it isn't.
- Autocomplete never stops working. It does sometimes get slow (several seconds)
- I have automatic compilation on save (no incremental config), manual/explicit saving. It's a workflow I'm happy with.
- 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 and with a full icon on the left) - or rather, no more than Eclipse in Java does (the kind where you have to refresh / clean the project do sometimes happen). On some constructs it will show a spurious "presentation" compiler error (red underline, simpler icon on the left), but it's easy to visually tell the two apart. I never think code is broken when it isn't.
- Autocomplete never stops working. It does sometimes get slow (several seconds)
- I have automatic compilation on save (no incremental config), manual/explicit saving. It's a workflow I'm happy with.
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 :)
> - 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 :)
> 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"
Oh, I didn't realize you meant hovers; I never use that (even in Java), I always use the pane with the variables in.
> In my experience, autocomplete sometimes stops working completely.
I sometimes get the "autocompletions took longer than 2 seconds to complete" warning, but after I dismiss it they are there.
Oh, I didn't realize you meant hovers; I never use that (even in Java), I always use the pane with the variables in.
> In my experience, autocomplete sometimes stops working completely.
I sometimes get the "autocompletions took longer than 2 seconds to complete" warning, but after I dismiss it they are there.
An additional answer to your bonus question is https://github.com/xored/scala-js-react
Which allows the following syntax: @scalax def render(self: This) = { <div>Hello {self.props.name}</div> }
Which allows the following syntax: @scalax def render(self: This) = { <div>Hello {self.props.name}</div> }
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)
To add to what @sjrd said, while you cannot import Java classes, porting Java code to Scala.js is way easier than porting to Javascript ;-)
Yea. However, wouldn't you think that the current trend in JavaScript makes this a confusing endeavour in terms of what the end result really is?
Nope. The current trend in JavaScript has nothing to do with a type system.
Here, you have one industrial-strength statically typed language that you can write both the front-end and the back-end in. The end goal is to simplify the development of complex web apps, the thesis statement is that static types could make this end goal easier to reach.
Here, you have one industrial-strength statically typed language that you can write both the front-end and the back-end in. The end goal is to simplify the development of complex web apps, the thesis statement is that static types could make this end goal easier to reach.
I personally hope that within some time this could be adopted on the large scale, I really feel the need for a statically typed language for the front end.
However, the biggest obstacle I can see is the learning curve.
I'm concerned that using Scala.JS will complicate cause there's a lot more to Web Apps than just JavaScript. And JavaScript works very well in the context of HTML etc. 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.
Using Scala adds a 4th language cause the JS is inevitable.
Using Scala adds a 4th language cause the JS is inevitable.
I think you're misreading the situation. Scala.js sits on top of Javascript, and leverages everything in the JS ecosystem. Interoperability is central to the Scala.js story.
For example, I'm building a product with a moderately complex front end. I'm using about 10-15 JS libraries, including JQuery and JQuery UI, as part of that. I just write a strongly-typed facade on top of each library, describing what it does (which takes just a few minutes), and I'm off to the races. Similarly, other folks are doing things like writing Scala.js adapters for React, Angular, and so on.
So Scala.js isn't in competition with the existing JS libraries. Far from it: I think of it as a much better way to use the Javascript resources that already exist...
For example, I'm building a product with a moderately complex front end. I'm using about 10-15 JS libraries, including JQuery and JQuery UI, as part of that. I just write a strongly-typed facade on top of each library, describing what it does (which takes just a few minutes), and I'm off to the races. Similarly, other folks are doing things like writing Scala.js adapters for React, Angular, and so on.
So Scala.js isn't in competition with the existing JS libraries. Far from it: I think of it as a much better way to use the Javascript resources that already exist...
> 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 is terrifying. Compiling to JS from a more typesafe language makes sense, and you can write bindings for most JS libraries.
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 is terrifying. Compiling to JS from a more typesafe language makes sense, and you can write bindings for most JS libraries.
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 JS, even if that just ended up being checked at run-time, because it gives you some of the big advantages of static typing without sacrificing all the of the dynamic goodness.
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 JS, even if that just ended up being checked at run-time, because it gives you some of the big advantages of static typing without sacrificing all the of the dynamic goodness.
Try Facebook's flow.
http://flowtype.org/
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.
Think of Scala as a library for JavaScript. It's keywords are no more or less a part of JavaScript than jQuery's '$' or CoffeeScript operators.
Unlike CoffeeScript though, using Scala to generate JavaScript does not require attention to the way JavaScript works any more than JavaScript requires attention to x86 instructions when run on V8 via Node.
Unlike CoffeeScript though, using Scala to generate JavaScript does not require attention to the way JavaScript works any more than JavaScript requires attention to x86 instructions when run on V8 via Node.
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.
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.
The other 3 languages being HTML, CSS & JS
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.
The important thing is that it doesn't grow proportionally.
Adding a second line to your "Hello World" doesn't give you 7000LOC, just like using jQuery in two places instead of one doesn't automatically double jQuery's library size.
Adding a second line to your "Hello World" doesn't give you 7000LOC, just like using jQuery in two places instead of one doesn't automatically double jQuery's library size.
> It’s mostly about the strong typing for me. Nothing revolutionary about that idea, but it’s just as true on the client as on the server: having the compiler type-check your code makes it much quicker to get complex, sophisticated systems up and running.
I used to believe that this was obviously true. Then I went from doing a lot of programming in JS where even with a large codebase, I could see the code fail in seconds to programming in Scala where type errors would not always appear in the editor, but you'd have to do a compile step that takes ages to actually see them.
Now I'm much less sure about the benefits of typing. What is actually useful is fast failure and short iteration cycles. Seeing the errors as you write is the fastest failure there is, but if I have to run a 30 second build to see a type error, that is much worse than dynamic types but seeing the error in less than a second.
Its true that carefully thought about types can catch errors you might not see immediately, but you can fix this to some extent with putting effort into making sure your code fails fast, and adding unit tests and while this doesn't give you proof-level guarantees, for most practical work, with discipline, it's good enough (even if emotionally unsatisfying).
Maybe one day I'll find a system that lets me encode constraints into the type system and have it actually tell me about violations quickly, and I'll happily leave dynamic land behind (for most things), but I've come to the conclusion that arguing about type systems misses the point, and the point is that failing fast is better than failing late. Within a single environment, failing at application startup is better than failing at an arbitrary point in the future. Failing at compile time is better than failing at startup. Failing at edit time is better than failing at compile time. But if your compile time is slower than my runtime, you're losing.
I used to believe that this was obviously true. Then I went from doing a lot of programming in JS where even with a large codebase, I could see the code fail in seconds to programming in Scala where type errors would not always appear in the editor, but you'd have to do a compile step that takes ages to actually see them.
Now I'm much less sure about the benefits of typing. What is actually useful is fast failure and short iteration cycles. Seeing the errors as you write is the fastest failure there is, but if I have to run a 30 second build to see a type error, that is much worse than dynamic types but seeing the error in less than a second.
Its true that carefully thought about types can catch errors you might not see immediately, but you can fix this to some extent with putting effort into making sure your code fails fast, and adding unit tests and while this doesn't give you proof-level guarantees, for most practical work, with discipline, it's good enough (even if emotionally unsatisfying).
Maybe one day I'll find a system that lets me encode constraints into the type system and have it actually tell me about violations quickly, and I'll happily leave dynamic land behind (for most things), but I've come to the conclusion that arguing about type systems misses the point, and the point is that failing fast is better than failing late. Within a single environment, failing at application startup is better than failing at an arbitrary point in the future. Failing at compile time is better than failing at startup. Failing at edit time is better than failing at compile time. But if your compile time is slower than my runtime, you're losing.
Error highlighting is usually instantaneous.
Not my experience in scala. I've had a lot of places where in the Scala plugin for intellij, it incorrectly highlights errors, or doesn't discover the error until a full build.
More and more languages have that now (F#, Ceylon, Haxe,...), I wonder how well it works in practice, especially in terms of:
- libraries availability
- code size and speed
- debugging capabilities
- ...and interoperability with JS (I recall that F# uses TypeScript definition files, that's a nice approach)
Anyone has more experience with it?
- libraries availability
- code size and speed
- debugging capabilities
- ...and interoperability with JS (I recall that F# uses TypeScript definition files, that's a nice approach)
Anyone has more experience with it?
- library availability: in Scala.js you have quite a number of core libraries available (see www.scala-js.org), but you also have direct access to JavaScript libraries
- interoperability with JS: Scala.js has its own TypeScript-like definition classes. But you can also interop in a dynamically typed way with the js.Dynamic type. In any case, the interop is very natural. Even the Scala syntax is close to JS syntax so method calls and property access just look the same.
- Code size: not exactly great, but manageable.
- Code speed: Scala.js has a very good optimizer that brings down typical macro benchmarks between 0.7x and 2x the time of the JS version (yes, 0.7x means it's actually faster!)
- Debugging capabilities: because of Source Maps, you basically step through your Scala.js code and step break points right inside your browser. All modern compile-to-JS languages have that.
- interoperability with JS: Scala.js has its own TypeScript-like definition classes. But you can also interop in a dynamically typed way with the js.Dynamic type. In any case, the interop is very natural. Even the Scala syntax is close to JS syntax so method calls and property access just look the same.
- Code size: not exactly great, but manageable.
- Code speed: Scala.js has a very good optimizer that brings down typical macro benchmarks between 0.7x and 2x the time of the JS version (yes, 0.7x means it's actually faster!)
- Debugging capabilities: because of Source Maps, you basically step through your Scala.js code and step break points right inside your browser. All modern compile-to-JS languages have that.
Link to F#-to-JS compiler?
FunScript: https://github.com/ZachBray/FunScript/
WebSharper: http://www.websharper.com/
Blue Storm: https://www.assembla.com/spaces/bluestorm/wiki/
I got these from: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
WebSharper: http://www.websharper.com/
Blue Storm: https://www.assembla.com/spaces/bluestorm/wiki/
I got these from: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
How about running Scala in multiple threads? And how about dealing with structurally-shared data?
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.
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. Especially when it comes to UIs, which need the responsiveness.
EDIT: web-workers are not a solution, because you can't share large data-structures efficiently between web-workers.
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. Especially when it comes to UIs, which need the responsiveness.
EDIT: web-workers are not a solution, because you can't share large data-structures efficiently between web-workers.
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.
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.
Mozilla is working on a type of array that can be shared.
The DOM is your structurally shared data. You just need to find a way to represent your data as (hidden) DOM nodes.
That actually doesn't work in this case, because Web Workers can't access the DOM.
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 cache, the UI is lightning fast afterwards...
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 cache, the UI is lightning fast afterwards...
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.
Hello worlds are about 100 KB not gzipped, but this is not a good measurement. As your application grows, this doesn't grow as fast. Scala.js is meant for medium to large size applications anyway.
Simple Scala.js JS "binaries" are quite big (from ~170kb before compression) because they add the part of the Scala standard library that they need.
From there, though, output size does not increase fast.
From there, though, output size does not increase fast.
Mine is 20kb after google closure optimization. 139kb unminified.
I can't wait for nice bindings to a JS plotting library (something on top of D3). One of the big missing parts of Scala for analysis...
Here you go: https://github.com/quantifind/wisp
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...
[0] http://www.oracle.com/technetwork/articles/java/jf14-nashorn...
[0] http://www.oracle.com/technetwork/articles/java/jf14-nashorn...
It's already out in Java 8 but the parser can choke on large js files. I tried loading some Ceylon code compiled to js into the webview but it froze. I think it will have the same problem with Scala.js
How much of Scala and its APIs can be used? For example can you use Scala Actors in Scala.js?
[deleted]
This is awesome, thanks to the scala.js team and community for the hard work.
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.
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.
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.
oh god! it was fine as an experiment but...
Stop the programming language proliferation madness!
Looking at broader trends, there is a clear movement towards static typing on the Javascript VM, as in-browser programs become more complicated. Google is developing SoundScript, there has been talk about gradual typing in ES7, Facebook has their type checker etc. To some extent I think adding static types to (the mess that is) Javascript is more work than may be worthwhile. I see the most practical developments in the alternative JS languages, such as Elm and Purescript, and now Scala.js, that start from a cleaner slate. The Javascript committee have done a shockingly good job making Javascript a compilation target with tail calls and so on in ES6.