[joshuahornby]

Having worked on a small/medium React application after stepping back once the work was complete it began to dawn on me that React wasn't the holy grail of web development. The number of packages needed in order to glue parts together, the managing of state at times is just confusing and on boarding new team members can be painful. Not to mention the constant battle with updating packages and API churn of these packages. But what React does have is an incredible community and a very large backing (Facebook). There is also some very intelligent people working on React (https://twitter.com/dan_abramov, https://twitter.com/schrockn, https://twitter.com/soprano to name a few)

The idea of Elm (http://elm-lang.org/) excites me greatly but then again what's to say that Elm will be dead in a years time? My question, is there a framework out there that mixes the better parts of React (virtual dom, large community), the idea of functional programming and a server side aspect to build the back end in one package?

[ssmoot]

If you're doing Scala/Play development, then I kinda feel like you should just use Scala.js. So you get a familiar language, providing the same sort of benefits as Elm, that almost definitely will be around for years to come. There are concerns with the size of the generated code, but on balance it doesn't appear significantly worse than most of the JS frameworks available.

I realize that's a suggestion that will only apply to a relatively small niche in comparison to many of the frameworks discussed, but since I'm a part of that niche... :)

But yeah, you probably should be using something better than ES5. So is it Typescript? Elm? Clojurescript? etc? I think Elm is out. And while the others are probably good, long-term solutions, why learn a new language if you can get more or less the same feature set with something that already integrates with your build-tool/stack? Seems like a no-brainer to me.

And then once you have that, do you really want a client-side "framework"? For some problems maybe... but I feel like if you solve the basic problem of language, that question becomes a lot less relevant.

Just seemed like an appropriate place to vent my own thoughts on the subject lately. I get there are plenty of people that don't care for or aren't excited about Scala for one reason or another, so I'm not attempting to persuade anyone it's the right choice for them.

[joshuahornby]

Bear in mind I am asking this question as someone who has no experience in Scala/Play but is looking to learn some new languages/frameworks:

How do the Play framework and Scala.js work with each other? Can I easily write an application is Scala and then sprinkle Scala.js around to perform AJAX data fetching for example?

[ssmoot]

For someone who knows Scala the tutorial at http://www.scala-js.org/tutorial/basic/ seems pretty thorough.

But the short answer is yes.

There's also this: https://github.com/vmunier/play-with-scalajs-example

And then if you want something interactive but with low commitment, you can give the examples in Typesafe Activator a spin:

  $ brew install typesafe-activator
  $ activator ui

That'll open a browser window. Form there you can open tutorials, step through them while a code panel gets highlighted as you go, edit code in-browser, execute tests and run. All from a single app running in your browser with a 30 second install. It's gotta be the lowest friction intro/development environment ever conceived. Highly recommended if you've never seen it.

[dustingetz]

Who uses scala.js? I was not under the impression that it was "ready".

[acjohnson55]

It's definitely ready! I can't speak to who's currently using it, but it's got a very impressive ecosystem around it, from when I looked into it months ago.

[slorber]

Let's talk about building an app with 50 independant ScalaJs modules then and how you manage/compose them in one or many of your apps without embedding multiple times the ScalaJs runtime.

Don't forget Scala is slow to compile and ScalaJs is even slower so if you have a monolithic js app it won't scale as a good developer experience.

I'm a backend Scala developer and I'd rather use Elm than ScalaJs until it's clear how to scale ScalaJs apps.

[xerious]

> how you manage/compose them in one or many of your apps without embedding multiple times the ScalaJs runtime

That doesn't make sense. You have code, maybe also dependencies. Scala.js compiles it and produces one JavaScript file with a single runtime and only the bits and pieces of your code and your dependencies that were actually used.

> Don't forget Scala is slow to compile and ScalaJs is even slower so if you have a monolithic js app it won't scale as a good developer experience.

ScalaJS incremental compilation is so fast that it's already done when you switch from the IDE to the browser.

[stcredzero]

The number of packages needed in order to glue parts together and the managing of state at times is just confusing.

Sounds like there's an opportunity to package a lot of those things together into a single Rails-like "opinionated" package.

[sotojuan]

Actually a few weeks ago there was a big movement in the React community about that. The problem is that the JS community is too big and people use different build systems and tests frameworks, let alone coding styles or project/files layout.

I think only Ember has been able to have a strong set of conventions, mostly thanks to ember-cli[1]. I consider it the Rails of JS.

That said, I am looking into nwb[2]. Looks fine for personal projects.

[1] http://ember-cli.com

[2] https://github.com/insin/nwb

[joshuahornby]

let alone coding styles or project/files layout

Agreed, the lack of project structure is in my opinion the biggest issues when building React apps. An interesting discussion on project structure can be found here: https://github.com/mxstbr/react-boilerplate/issues/27

[sotojuan]

Yeah I think it's one of the least talked about conventions, and unfortunately there's a lot of debate because of how React is (CSS next to component or in its own place?, etc).

[EvanPlaice]

Coding styles is a solved problem. Use the feross/Standard tool or SemiStandard equivalent (ie if you prefer semicolons).

Structure arguments will continue until the past decade of brain damage caused by trying to shoehorn MVC into front-end frameworks wears off.

The future is self-contained, reusable web components. Organize the structure by feature. Provide a root file that acts as an exports facade that maps the internals to an easy-to-understand public API.

[EvanPlaice]

Correction: I'm not implying that separating of concerns is bad.

I'm saying that arbitrarily separating them into folders by-type at the base level is not a useful pattern when it comes to reusability.

[config_yml]

Ember.js

It's not perfect, it feels a bit big sometimes, but everything I need something to build a feature quickly it's there in the framework or the build tool, and that's good enough for me.