Scala.js no longer experimental
scala-lang.org
scala-lang.org
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.
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.
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.
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.
I will remember this one. That's a great question for interviews.
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.
- 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/
As are applets - a great idea, implemented poorly, and now essentially lost to the annals of history.
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).
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.
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.
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...
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.
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.
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?
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.
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.
This may have changed since I was last working with Clojurescript.
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.
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 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 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
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
Just look at the sorting library of Go. I don't think they have solved the problem of static types in a satisfactory way.
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?
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.
[1] http://docs.scala-lang.org/overviews/macros/overview.html
Maybe someone can explain this.
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?
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.
- 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?
- 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.
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
Which allows the following syntax: @scalax def render(self: This) = { <div>Hello {self.props.name}</div> }
- 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.
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?
- 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.
> - 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 :)
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.
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.
Using Scala adds a 4th language cause the JS is inevitable.
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.
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.
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.
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...
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.
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.
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.
- 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?
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...
- 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.
Also, all of Scala's collections, including the persistent ones are supported.
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.
From there, though, output size does not increase fast.
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...
[0] http://www.oracle.com/technetwork/articles/java/jf14-nashorn...
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.