5 ms·

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

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/dan_abramov, https://twitter.com/schrockn https://twitter.com/schrockn, https://twitter.com/soprano https://twitter.com/soprano to name a few) The idea of Elm (http://elm-lang.org/ 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?

stcredzero 11y ago
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 11y ago
  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 http://ember-cli.com [2] https://github.com/insin/nwb https://github.com/insin/nwb
  - joshuahornby 11y ago
    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 https://github.com/mxstbr/react-boilerplate/issues/27
    - sotojuan 11y ago
      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 11y ago
    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 11y ago
      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 11y ago
  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.
ssmoot 11y ago
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.
- dustingetz 11y ago
  Who uses scala.js? I was not under the impression that it was "ready".
  - acjohnson55 11y ago
    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 11y ago
      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.

stcredzero 11y ago

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 11y ago
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 http://ember-cli.com [2] https://github.com/insin/nwb https://github.com/insin/nwb
- joshuahornby 11y ago
  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 https://github.com/mxstbr/react-boilerplate/issues/27
  - sotojuan 11y ago
    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 11y ago
  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 11y ago
    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 11y ago
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.

ssmoot 11y ago

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.

dustingetz 11y ago
Who uses scala.js? I was not under the impression that it was "ready".
- acjohnson55 11y ago
  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 11y ago
    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.