Udash – Scala and Scala.js Reactive Web Framework | Hacker News Reader

Udash – Scala and Scala.js Reactive Web Framework

udash.io

158 pointsauggierose45 comments

I did a couple of blog posts about UDash recently, one of which was to view this very site using functional programming library Fetch (similar to Facebook's HAXL)

http://justinhj.github.io/2017/10/11/hacker-news-api-3.html

The other was a simple roman numeral converter

http://justinhj.github.io/2017/08/27/roman-numeral-tool-with...

For me the advantage of UDash is for people that want a type safe Scala "all the way down" web application. One of the downsides is that is difficult to avoid runtime errors, at least to the extent that Elm does (by design).

Another drawback is not being able to simple share a template with designers; they would have to be proficient in Scala at least to the extent they can fix compile errors in the page code.

Some plus sides are that it plays well with Twitter Bootstrap and type safe CSS.

Can you expand on why it is difficult to avoid runtime errors when everything is typesafe?

This was from personal experience where code that would compile correctly would give a runtime error in the browser. Could be that I didn't know enough about UDash to fix it, but the error was unhelpful so I worked around it.

If people don't want the entire UDash experience there are smaller libraries:

Binding.Scala https://github.com/ThoughtWorksInc/Binding.scala

React https://github.com/japgolly/scalajs-react

RPC https://github.com/shogowada/scala-json-rpc

Shameless plug: I found the complex type/macro/implicits mixture in scalajs-react hard to work with and made a wrapper that’s simpler to use:

https://github.com/Ahnfelt/react4s

This looks fantastic, nice work! Does it work with React Native?

Thank you :) I have not tried to use it with React Native. There's no fundamental reason why it wouldn't work, but it hasn't been tested. If you try it out, I'll do my best to help you make it work.

This is awesome. Clojure has had similar frameworks for a while, but Clojure has a fairly steep learning curve. Really excited to try this in Scala. Wonder if this will be a new trend away from the totally separate webapp + rest API model...

I use Scala daily and have never used Clojure - what creates the steep learning curve? Scala also has a lot of features between “Beginner” and “Advanced” which can really add to the learning curve (Implicits being a good example).

I haven't tried Clojure yet, but compared to Common Lisp, Scala let's you ease into the advanced features but lisps demand an immediate shift in thinking. You can basically write Java with Scala without much friction.

It lets you ease into it insofar as you don’t use libraries that heavily rely on more advanced features. Trying to understand how Circe is actually serialiazing your case classes (Or why it is failing) can be quite difficult without understanding Shapeless.

It took me weeks to get Circe working on my project.

But this compiler plugin makes it infinitely easier: https://github.com/tek/splain

Wow going to plug this into a project and try it out tonight, might be worth adding as a default plugin to projects - looks good on the surface.

Fair enough but I still think avoiding those libraries is very doable. Personally I used play-json without the rest of the play framework and it is robust and easy to grok.

Oh man I had the misfortune of starting scala with a framework( akka http) that used magnet pattern. Turned me off from scala forever till I rediscovered it again.

I am very much in the minority but I can't stand most of Akka.

It's overly engineered with too much clever magic and hence is very reminiscent of frameworks like J2EE Spring which is why people left Java to begin with.

From my non-substantial experience in Clojure and Scala, I'd say that Clojure is simpler and faster to learn and get productive quickly than Scala. Scala has lot more syntax and concepts that you need to grok compared to simplicity of Clojure.

I'm curious why you say Clojure has a steep learning curve.

Clojure has a steep learning curve because it's purely functional.

Most programmers grow up with learning OOP and so throwing all of that out and asking you brain to do everything in reverse is challenging. I know having worked with a dozen J2EE developers in their transition to Clojure. It took at least 3 months to just be productive.

Scala for many people is just Java with a sprinkling of functional and they never really bother to learn the internals or the more complex areas like generic programming e.g. Shapeless/Cats.

IMO it's just the syntax that comes across as really bizarre. Scala is much more complex than Clojure aside from the initial hurdle of getting used to that syntax.

Personally I think it's less about FP vs OOP -- even if the OO parts of Scala are familiar, you're going to encounter FP code in Scala, and in general there is a lot more to learn with Scala as a language just to be able to read other people's code effectively.

Clojure has the easiest learning curve I've ever experienced, it took 3 days to bring my co-founder (a Scala dev) up to speed. I am also a former scala dev, I flatMapped that shit, etc. That Scala coolaid tasted far better going down as a starry eyed 20-something than it did on the way back up ... Scala's own source code is incomprehensible, let alone the emergent monstrosities built by well meaning humans that aren't in the top 1000 scala experts on the planet... Scala, fundamentally, simply doesn't make any sense at all, it was a bad idea, you can't fuse OOP and FP without violent and polarized flamewars and fracturing the community into incompatible sects. The experiment failed.

I think what has failed is in fact Clojure's experiment of doing FP without a type system, now that they have to bolt it on with runtime type checking.

OOP + FP is actually doing quite well, look at Swift, ReasonML (essentially OCaml, which is also doing fine by itself).

> "now that they have to bolt it on with runtime type checking."

I think that's definitely in the eye of the beholder. The overwhelming opinion I've heard from those in the community is that they greatly prefer having the option, but wouldn't want it required. And that's exactly what spec provides. The language isn't perfect (and honestly, what language is, for every purpose?) but calling it a failure is quite hyperbolic.

> but calling it a failure is quite hyperbolic.

as is claiming that Scala is a failure. If adoption and widespread use across industries (big data, hardware, server, web, etc.) is any indicator of success, Scala is just that.

The reality is that both languages are excellent; if you work in either for the day job you're fortunate -- there are far worse languages out there.

> "as is claiming that Scala is a failure."

Agreed, and I admit I didn't see this as a response to 'dustingetz' equally hyperbolic criticism of Scala. Answering hyperbole with more hyperbole is rarely a way forward for constructive discussion.

Scala's purpose as stated by Odersky is a research experiment in fusing OOP and FP. That experiment has clearly (to me at least) failed. Everyone who gets to be any good at Scala eventually migrates to Haskell or Clojure, because both hit the high notes of functional programming with a vastly simpler model and better outcomes. Scala is a great gateway drug to FP because it is easy for enterprise Java developers to hit the ground running, but java devs don't write good scala code so we start to see the ecosystem fracture into sects, like C++ and we all know how that turned out.

> Scala's purpose as stated by Odersky is a research experiment in fusing OOP and FP.

It's odd that across so many industries companies would adopt an experimental language; it's almost as if Scala was a stable, production ready language, a successful one even, and that some people have opinions, well founded or not.

> Everyone who gets to be any good at Scala eventually migrates to Haskell or Clojure

The number of Scala developers migrating to Haskell far exceeds that of those migrating to Clojure, probably by a factor of 100X.

> like C++ and we all know how that turned out.

a resounding success? "There are only two kinds of languages: the ones people complain about and the ones nobody uses." Which of the FP languages at hand do people complain about?[1]

[1] https://trends.google.com/trends/explore?q=%2Fm%2F091hdj,%2F...

Failed how? Seems to be thriving for many use cases. I’m a fan lisps and Clojure especially but it didn’t scale to large teams and problems the way Scala does

It looks really verbose only to render simple html.

I had one really bad experience with Scala.js. When I used it, I noticed Scala was just not designed for the web (front end) and it just didn't work well for things really simple in JS.

Scala.js is not really designed for simple websites.

It's designed for bigger ones especially in which you want to share models and validations between front and back end.

I'm going to go against the HN current opinion but I hate Scala. I worked for a few months on some Scala projects, the language is way too complex (the opposite of Go, they add whatever feature they think is cool) is poorly documented and readability is difficult as well. It looks like a mix of Perl and functional languages.

I hate it as well. I think it's a poorly designed language. The syntax is a mess (underscore...), the operator overloading make people overload silly operators which make code unreadable from an outside programmer. I could go on...

I prefer Kotlin which imho fix almost every bad design decisions from Scala.

If underscores and operator overloading are the biggest criticisms you have of Scala, then we're doing pretty well. For what it's worth, I think Scala has quite a large grammar that means it takes a while to learn, but once that's over it's not particularly difficult to read or to write.

Can you elaborate as to what Kotlin fixes compared to Scala?

Could you cite an example of how Scala is unsuitable for the web? Between Scala and JavaScript, I would pick Scala in a heartbeat for one reason alone - it's strongly typed. Both of them offer OO & FP.

Strongly typed was one of the problem I found. TypeScript offers a better alternative to typing on the web because it keeps the compatibility with javascript and also have a real any type when it's really necessary. Typescript now can import raw js without types definitions unlike Scala.

I believe Scala can use javascript libraries either dynamically or with type definitions in exactly the same way as TypeScript?

I tried to use TypeScript but the type system just wasn't good enough; when you've been working in a strongly-typed language like Scala for a while, a language without nominal types or HKT just isn't going to cut it.

Could you illustrate, preferably with an example, how weak type system would have worked better than a strongly typed system?

You can do FP in any OO language. OO is an extension on top of FP.

This actually looks really cool. I really like the idea of RPC over websockets built into the framework, I don't do much webdev anymore but I dont think I've seen that before. Looks like a really solid project

RPC over websockets is basically how Meteor worked. Although it seems that’s sort of being deprecated in favor of GraphQL.

Good to know!

The problem with these things is that I can't give my web developer a bunch of Scala files to edit instead of HTML. Does it support binding in HTML templates too?

Is there a runtime lib? That includes e.g. Scala collections for the browser for example? How many kilobytes?

> Is there a runtime lib? That includes e.g. Scala collections for the browser for example?

Pretty much all Scala code compiles with Scala.js, that includes the Scala standard library, as well as part of the Java standard library that has been reimplemented in Scala.

> How many kilobytes?

Scala.js does whole program optimization and dead code elimination, so there's not a single number that can be given here, you pay for what you use.

> so there's not a single number that can be given here, you pay for what you use.

While true, in practice as soon as you use, for example, `List`, `Map`, and `Option`, along with various basic collection operations (`flatMap`, `map`, `zip`, ...) you've pulled in basically the entire standard lib*

Wind up paying about a 160KB baseline "tax" to use Scala in the browser, which is well worth it considering that you can ditch jQuery and related plugins (DataTables, Validation, etc.), shedding far more weight than Scala.js in the process. I find it to be a huge win, wish I could use it in current bloated Angular 5 + TypeScript project :\

* This is due in part to existing collections library that is not so amenable to dead code elimination (or at least google closure compiler can't track the full reach of CanBuildFrom's tentacles :)) Maybe this will change in Scala 2.13 collections overhaul, have my doubts, doesn't sound like the new design is radically different than the current one.

This is just great. This is the web framework I have been hoping someone would make!

Reply on news.ycombinator.com