Scala.js for large and complex front end apps [video] | Hacker News Reader

Scala.js for large and complex front end apps [video]

youtube.com

70 pointslihaoyi24 comments

I actually tried this route, considering that I was writing a backend in Scala, was familiar and comfortable with Scala, and I absolutely loathed the idea of learning Javascript. As it turns out, without an ecosystem with more complete project support, documentation, stack overflow questions, and far more members, you still have to know javascript and even worse you have to know how Scalajs compiles down to javascript, along with how it is built and packaged. Having a problem with the scala version of the react library you want to use? Write up a question for stack overflow, post an issue on github, and then hunker down in the source code and try to find the answer on your own while waiting a few days for a response. I couldn't deal with the lag, at least not for a project that is more than a toy.

I honestly wish I could use Scala in the browser. I'm using Typescript instead. The compilation down to ES6 is so trivial that I don't have to try to guess what the compiler is doing. I can read javascript code and documentation and almost never have trouble figuring out how I would write the same thing in TS. I get the primary benefit of static types, even though I don't get all of the ADT and pattern matching goodness. IDE support in Atom is excellent. Compilation is fast. And the community is large enough that I can usually find an answer quickly through the normal SO, IRC, email list channels.

I'm tempted to rewrite your comment using s/Scala/JavaScript/g and then wager it would still make perfect sense. I've recently had to bootstrap an Angular project using nothing but pure JS and some Sass. This isn't my first in-browser UI, but the first after a long break from heavy front-end development.

My impression is that the quality of tools in the JS world is so damn low, that they're more of a hindrance than help. Gluing together Grunt, Sass, Bower, NPM, Browserify, Uglify and a bunch of internal libraries was a titanic task.

By contrast, in the Scala world tools are easier to reason about, fail more cleanly and usually surface problems at compile/build time.

Trust me...I absolutely prefer scala as a language. I love almost everything about it (except maybe SBT, but it's tolerable). It pains me to know that the TS compiler is catching only a fraction of the problems that Scala could. But ultimately anything I write has to end up as javascript, and the community just isn't there to support it, so I end up having to deal with javascript regardless.

And yes, the js tools are loathsome in general. I've found Typescript to be the best tool available to me, and webpack is pretty good as well. Everything else I've been able to cut out thankfully.

Oh, webpack is a great example of my frustration: I suspect it might be better than browserify for my needs, but I'm already so shell-shocked from adopting browserify at work that I no longer have the nerve to disturb the house of cards that I've built here. Thus webpack will have to wait.

Anyway, I hear you, although the only way to make Scala.js work better for everyone is to use it. Otherwise building a community is an insurmountable chicken-and-egg problem.

> You still have to know javascript

Yes, you have to be familiar with the underlying platform. This is also true for languages running on top of the JVM, as you have to be familiar with the JVM and Java's ecosystem and with POSIX and with the target operating system and so on. And that's not just for Scala and the JVM. Don't get me wrong, you don't have to be an expert, but some knowledge of your underlying stack is always required.

> Having a problem with the scala version of the react library you want to use? Write up a question for stack overflow, post an issue on github, and then hunker down in the source code and try to find the answer on your own while waiting a few days for a response.

Isn't that, you know, how programming works? Yes, you end up interacting with other people through GitHub Issues, Gitter/IRC channels, StackOverflow, etc. It's actually rewarding, because you end up learning a lot. Us developers, we tend to be introverts. It's hurting us ;-)

> The compilation down to ES6 is so trivial that I don't have to try to guess what the compiler is doing.

It also means that Typescript is barely a step up from Javascript, so why bother? If you're going to be hip and choose an option that isn't THE mainstream choice, don't you want to pick something that brings enough benefits, to counter-balance the disadvantages of not going for straight Javascript?

Scala is a statically typed language in a way that Typescript will never be. Scala enables functional programming in a way that Typescript will never do. For all the bitching and moaning about Scala's SBT build tool and Maven's repositories, it's light years beyond the clusterfuck in Javascript's land when it comes to build tools, continuous integration and dependencies management.

And the best part of Scala.js is that you get to use many Scala libraries that are now cross-compiled. That means for example many of the Typelevel libraries, like Simulacrum, Cats, Shapeless, Spire and as a shameless plug, my own Monix: https://github.com/monixio/monix/

Scala's ecosystem isn't huge, like that of Java or Javascript, but you know, libraries tend to be in much better shape. For example Scala always had good Future implementations (again, versus the clusterfuck that happened in Javascript) and now Scala has Scala-Async which gives you async/await keywords without having to sacrifice browser compatibility: https://github.com/scala/async

Have a problem with React? Fix it. That's how you and the community can grow.

> Have a problem with React? Fix it.

That's not how things work in the real world and you know it. Furthermore if you're good enough to fix React then you're good enough to write a complicated JS codebase without the need for a third party language.

> It also means that Typescript is barely a step up from Javascript

Typescript is a huge step up from Javascript has it brings type safety, which eliminates a whole class of errors, make the code easier to read and document and the price to pay for using TS is quite low compared to using Scala.js .

Scala has its place, but right now it's definitely not in the front-end.

Scala.js makes sense when everyone on your team works on every level of your stack - generally smaller teams without any specialization.

I'd agree with the other commenters that it makes a lot less sense if you are hiring outside front end devs. You'd probably have a lot less friction if you stick to something more mainstream - either pure Javascript or maybe typescript.

Since my project (https://invotes.com) is a one man operation written purely in Scala at this point, I've used Scala.js on the front end with great results. It's nice to be able to cross compile common functionality between the server, frontend, and Android. I haven't run into any blocking issues between the three platforms. It's also pretty straightforward. I hadn't used Scala at all prior to this project, but most everything makes sense (and I don't even have a problem with SBT).

The biggest downside is the increase in JS size, but at this point it's not too unexpected to have an overall page size at ~1mb, and at least it's all one minified file once it goes to production.

I actually proposed this route where I work. We have a decade old large and complex front end JS app, and my suggestion at improving it was to replace and rewrite most of it in scalajs in a phased manner. We already have a ton of Scala engineers working on hbase, presto and Spark on the back end, so why not hire a few who can do Scala on the front end as well ?

The response from the front-end guys was mostly not pretty. Over time I've come to realise the cultures are miles apart. Scala devs really value type systems and FP and all its benefits - the JS guys value very different things. The hotchpotchness of tools and frameworks in that world is actually seen as a plus point, as diverse devs collaborating, as some community thing. I will never understand it.

My feeling from a business point of view is: with Scala devs being a) relatively scarce in the market and b) the salary attached to a Scala dev, why would I spend their time getting them to write that's going to end up being JS when a highly skilled JS dev can be found easier and costs less (if you have both already then the relative opportunity cost difference).

Add time for compiling, edge cases, bugs and no matter how awesome it is, I can't see how it ever makes sense outside of a 1 person project.

When the compiler eliminates huge classes[1] of bugs you can afford to hire fewer devs and not suffer any loss in quality. Salaries are a huge part of why software development costs as much as it does.

[1] Yes, classes. As in: You can never misspell an object property and have that mistake make it into production (&c for lots of other types of bugs). Plus, you get automatic refactoring you can actually rely on. Now, your JS devs may not appreciate that, but I suspect that's just because they're inexperienced and/or haven't actually worked in a good[2] statically typed language. There's also the fact that we (as humans) unconsciously try to minimize our own mistakes; "oh well, it was just a typo and we fixed it quickly!" and for most of us mistakes tend to fade quickly from memory... thus leading to a very biased view of one's own development practices which doesn't take into account how many mistakes you really make.

[2] I'm going to do a D. F. Wallace here[3].

[3] ... and say that Scala isn't great as languages go[5], but I'll bet you it's a hell of a lot better than any statically typed language your typical JS devs have any experience with[4]. One particular gripe of mine is that they still permit "null", but that's because of Java compatibility. (Oh, how much better Scala could have been without Java compatibility.)

[4] ... which would obviously colour their perception of the trade-offs between static type checking and "verbosity", "bondage & discipline", etc.

[5] It is good, though.

I think that's enough footnotes for now.

EDIT: Sorry, I lied. Added another footnote. Really doing the DFW thing, but in Reel Time(TM).

If static typing is the selling point of Scala.js you might as well use TypeScript, which would be familiar to JavaScript developers.

No. Static typing in TS is very very far from what Scala can do[1]. Just as an example: Scala can do type inference (albeit local) which TS cannot do in any meaningful sense. There's a huge difference and you owe it to yourself to try it out for a real project!

[1] My company started out with TS, but after converting about 10% of our app from TS to Scala.JS + scala.js-react we just decided to convert the rest in a mad sprint over a few weeks. It has paid off in spades. We still struggle with the abomination that is CSS and separating styles from components, but it is what it is.

You're incorrect. TypeScript can do a lot of type inference. I've used TypeScript full-time for about two years, I don't have experience with Scala.js though.

I think most types for which you would care about type inference in Scala can't even be expressed in Typescript ...

Yeah. HKTs are one particular instance, though even Scala doesn't necessarily do particularly well on those compared to e.g. Haskell (well, GHC, really).

(It seems subtyping and higher-order reasoning just don't mix well. Undecidability abounds, unfortunately. I tend to prefer higher-order reasoning over subtyping.)

This is only true because after a few years the front-end guys want and probably get to re-write their code for some new design or the latest fizz-bang framework. So they don't have to refactor / maintain 5+ year old code.

I would look at Elm as if it compiles you will not get a runtime error but Elm devs probably are even more scarce then Scala devs.

Because scala code done well eliminates huge swathes of bug classes that are common in javascript. It may be worth it for "mission-critical" UI, or to rewrite lower-level UI code in stronger semantics.

The problem is how easy (or not) it is to interface scala.js with third party libraries not written in scala. js. I doubt scala has the same semantics as Javascript. If the semantics are too different it's not going to work unless you expect your engineers to write everything from scratch. Also there is a the speed factor. Is compiling to JS fast ? what kind of code does it produces ? how big ? is it easy to take a library written in Scala.js then interface it with plain old Javascript ? ect ... It's definitly not a culture problem, I believe using Scala.js or Gopher.js or Opal(Ruby) or any language which semantics are too different from Javascript is just not pragmatic.

I wonder how much of your comment follows from past experiences with other compile-to-JS languages.

Scala.js solved all the problems you mention.

* Performance is on par with hand-written JavaScript.

* The compiler and optimizer are incremental so they compile your code in 1-2 seconds for significant codebases.

* Interoperability is as easy as in TypeScript: just use type definitions for external JS libraries and then transparently call them.

It's all explained from the big boxes on the page of https://www.scala-js.org/

Don't let your past experiences give you wrong impression of Scala.js.

This is fantastic. Thanks for sharing.

I tried a similar argument using first-class iterables and/or channels to try to isolate state in a big project while still at a very, very major web company.

NOPE. Was on an all FE team. The one BE guy embedded with our team got it, the FE devs just looked at me with blank stares during my presentation.

How does this better than GWT?

GWT is weighed down heavily by its mission to be both a Java->JS compiler and a UI framework. Scala.js is, first and foremost, a Scala->JS compilation mechanism, and only incidentally can have a type-safe interface to UI (or any other) pure-JS libraries.

It's less "heavy"; more concretely it's less of a parallel world like GWT. It's not tightly coupled to its own standard library like GWT, and it's more amenable to integrating with (javascript-)native libraries.

Reply on news.ycombinator.com