Live data from Hacker News

From first principles: Why I bet on Scala.js

lihaoyi.com

61–70 of 90 posts

Re: From first principles: Why I bet on Scala.js

#62

It's a little strange that ClojureScript is omitted from the sections where it compares favorably to Scala.js, e.g.: > If you look at other compile-to-JS languages like: > - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskel…

I'm glad you pointed this out. That's way mal-informed for how you'd build that DOM in clojurescript. I mean, you _could_ do it that way, but there are libraries (like hiccup) that make it more natural.

Here's an example of a react component from the re-agent tutorial (http://reagent-project.github.io/), e.g., but you'd build straight html in the same-ish way using a library:

  (defn simple-component []
    [:div
      [:p "I am a component!"]
      [:p.someclass
        "I have " [:strong "bold"]
        [:span {:style {:color "red"}} " and red "] "text."]])

Re: From first principles: Why I bet on Scala.js

#63

It's a little strange that ClojureScript is omitted from the sections where it compares favorably to Scala.js, e.g.: > If you look at other compile-to-JS languages like: > - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskel…

I'm glad you pointed this out. That's way mal-informed for how you'd build that DOM in clojurescript. I mean, you _could_ do it that way, but there are libraries (like hiccup) that make it more natural. Here's an example of a react component from the re-agent tutorial ( http://reagent-project.github.io/ ), e.g., but you'd build straight html in the same-ish way using a library: (defn simple-component [] [:div [:p "I…

The point wasn't to show how to build HTML fragments, the point was to show javascript interop.

You could create a nice wrapper-library around anything in any-language, really, but that misses the entire point of that example: to show how interoperability is when you haven't wrapped a nice wrapper-library around everything.

Re: From first principles: Why I bet on Scala.js

#64
post #53

Earlier quoted context omitted.

Except for: types. That's a big deal about what the author liked about Scala.js.

It wasn't mentioned as a criterion, and OpalRuby, Python variants, and Coffeescript all got significant discussion in the article. The ClojureScript omission on all the axes other than "superficial similarity to JavaScript" is still pretty glaring.

If you read the whole post and didn't come out thinking "types are a surprisingly big deal", I have failed as a writer.

Re: From first principles: Why I bet on Scala.js

#66

Earlier quoted context omitted.

Not using an IDE for JVM-based languages is sort of like using pliers to drive screws. You can do it, but it's tiresome.

I used to only use plain editors until I started using scala, after which the benefits of an IDE became readily apparent. Unfortunately, all of the IDEs for scala are relative shit compared to their support for Java. It would be nice to be able to run an integrated debugger (as opposed to a port connection from an SBT spawned JVM), integrate directly with SBT (as opposed to having to run it side by side), provide a f…

Well, _the_ Scala IDE currently is Scala plugin for IntelliJ IDEA (works in Community Edition, which is free and open source). All these features work there.

Re: From first principles: Why I bet on Scala.js

#67
post #3

I wrote this; ask me anything

Which resources (books/tutorials) do you recommend for learning Scala.js for someone who does not know Scala or Java or any JVM language, but knows a decent amount of Python, Julia, Go, Javascript, Dart etc. I should add that I am not interested in JVM (at least, now). I want to know what are good resources if one intends to use Scala only for the JS side of things.

Actually you should start out with https://www.amazon.de/Programming-Scala-Martin-Odersky/dp/09...

Even when it's targeted at the JVM. Scala.JS usage isn't that hard after you read half of the book.

Re: From first principles: Why I bet on Scala.js

#68
post #3

I wrote this; ask me anything

Closure Compiler uses type annotations on variables and functions that give information on null and undefined. These annotations look like {?Object|undefined} (Object may be null or undefined) and {!Object} (object is guaranteed to not be null).

In Java, NullPointerExceptions is huge problem. IDEs have plugins to check for this error, but there is no standard solution.

Does Scala help in avoiding NullPointerExceptions? Do function signatures specify if a value may be null?

Re: From first principles: Why I bet on Scala.js

#69
post #4

3 things I don't like about Scala: 1. It's based on the Java platform. 2. It's excessive use of operator overloading. 3. Mad implicit conversions all over the place. (yes, I exaggrated a bit ;))

Roughly none of those points are true (anymore).

Nice to hear.

I came back to the JVM many times in the past and every time it was the same. It always seemed like things changed, but the baseline complexity stayed the same.

Re: From first principles: Why I bet on Scala.js

#70
post #68
post #3

I wrote this; ask me anything

Closure Compiler uses type annotations on variables and functions that give information on null and undefined. These annotations look like {?Object|undefined} (Object may be null or undefined) and {!Object} (object is guaranteed to not be null). In Java, NullPointerExceptions is huge problem. IDEs have plugins to check for this error, but there is no standard solution. Does Scala help in avoiding NullPointerException…

Scala does not have non-nullable types currently (but that might happen in the future), in practice this is not a problem simply because using null is seen as a code smell and basically no Scala library API expects parameters to be null or return null, optional values are usually represented with the standard library class Option: http://www.scala-lang.org/api/2.11.8/#scala.Option
Post reply on HN