Comment by noelwelsh | Hacker News Reader

Comment by noelwelsh | Hacker News Reader

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

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.

Yeah, you could maybe even get the JSX-style syntax with React by using Scala's XML support. I'm not sure if it would actually work, but it's a cool idea.

If you mean XML literals, they're deprecated now. I don't know whether the macroized XML interpolator has landed yet.

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

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.

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

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

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.

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.

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.

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

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

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.

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.

My guess is that Mozilla would never support it.

http://www-archive.mozilla.org/projects/blackwood/dom/

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

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.

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.

Google is developing SoundScript

Aren't they doing Dart as well? That has optional typing. Plus they have GWT, which is Java to JS.

Don't get me wrong, I'm super grateful to receive their fruits of labor for free, but this looks like a case of the left hand not knowing what the right hand is doing.

Don't forget the Google Closure compiler in advance mode.

Also AtScript, for the upcoming Angular 2.0: https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...

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.

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

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

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.

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.

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

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

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

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.

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/

Reply on news.ycombinator.com