The only reason I choose React today is the immense ecosystem around it. With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.
Also, along the topic in this thread, I've never met someone who used Clojure/script. It's why I ended up just using Node/Javascript in the end. It gets lonely in the Clojure cave.
I am sure you could find someone doing Clojure stuff if you searched for Clojure on meetup.com
Curious, does that apply to Angular/Ember?
I prefer the Angular approach. The initial learning curve is steep, but once you get over that, it becomes a rapid development framework, as all the pieces work together cohesively. The Angular CLI makes creating components, services, updating, etc a breeze, and helps maintain structure as your scale your app up. The core libraries (like routing, forms) are developed and maintained by Google, so you can expect a solid level of quality. The typescript-first approach means that your IDE can help you explore APIs, auto import, and work with third party libraries just as well. And the strong foundation provided by the core framework means that third party libraries have a better starting point upon which to supplement/extend.
Takes a bit of effort to learn, but once you are up and running with Angular things are pretty fast to put together.
Alternatively, you could use Akita, which is built on top of this basic model, but offers a ton of additional functionality and the ability to use Redux Dev Tools.
Finally, you also have NgRX, which is based on Redux--but also adds a ton of overhead and boilerplate. I actually opted for Akita since it is way more ergonomic and offers most everything I need.
Not seen Akita previously - will take a look. Thanks!
Additionally, baking in rx-js felt like a serious mistake- not only was there the roller coaster ramp up of learning angular, but helping others on the team learn rx-js on top of it while trying to be productive probably cut our output in half.
It didnt help that we had a mix of junior developers and experienced .net devs all learning at the same time- half the battle was explaining which feature came from ES2015, typescript, angular or rx-js.
Hindsight may be 20/20, but I am reasonably confident that we could have been significantly better off with react. Ember was never an option because they are only just now getting features react and angular developers have been taking for granted for years.
RxJS is actually one of my favorite parts to Angular, but it _does_ lengthen the learning curve quite a bit. Once you get past that, you can have amazingly reactive apps. One of my beefs with ReactJS is that it doesn't play as well with RxJS. Now that I think of it, you're not actually required to use RxJS with Angular: you can convert observables to promises (`toPromise()`).
I could see how having junior/new developers could make things a lot harder. I remember first learning typescript and having to keep the TS playground open at all times to see how it compiled to ES5.
Now though I find RxJS to be a really elegant mental model for dealing with asynchronous stuff. I wish there was more Reactive/Rx* stuff around in the things I work with. Its really nice.
Why do you need a specific forms or router library? Those are both things you can do with vanilla ES2015+ and React.
The library problem is self-inflicted, but it doesn't help that search engines tend to boost a lot of half-baked Medium posts about why you should use slightly-nicer flavor-of-the-month library to wrap something really basic like the fetch browser API.
As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure.
I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial.
I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.
I think that might depend on what you're trying to do. I'm guessing as you say you are unfamiliar with the JS ecosystem, that you were trying to do something relatively simple.
As a full-stack developer who does a lot of front-end dev, my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common. Not "every feature I try to implement common". But "every project has 2 or 3 features that need the flexibility" common. This is enough to make avoiding that pain very appealing.
I haven't had the same problems with Laravel or Django (haven't used Rails). And I think a key part of that is that Laravel/Django are still "just PHP/Python". Angular tries to put the proprietary string templating language in charge of everything. Which is painful.
Also: Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task. Then search for blog posts comparing advantages and disadvantages. And check for recent activity / outstanding issues. It only takes a couple of hours, and you get a library which is more tailored to your use case.
* I haven't actually use Ember. Only Angular.
I'm not a js developer, but picking libraries based on popularity seems a dubious idea if a sufficient number of other people are doing the same.
In this case, it seems to be a problem with the framework if certain parts can't easily be overridden and implemented with custom code. But this is a problem with one particular framework and not with the whole idea of a "batteries-included" framework.
> Angular tries to put the proprietary string templating language in charge of everything. Which is painful.
Probably yes. I have not used Angular, only skimmed the Ember documentation, and what I'm talking about is mostly its MVC structure and the basics it provides like URL routing, models (which is just a REST API client in the background), templates, etc. I'm assuming most of this can be overridden with custom JS for the areas that don't map to its structure well enough.
> Picking libraries is a skill you can develop.
True but my point is less about the complexity of picking libraries and more that these libraries are at its core still framework-agnostic. They are designed by different people, with different goals, skills and opinions, which means there's potential for interoperability bugs if you are unlucky enough to be using the wrong combination of libraries. In comparison, with a batteries-included framework I am more or less guaranteed that all the "batteries" will play nice together and will have a consistent API.
The Javascript ecosystem also moves very fast so even if you pick your libraries at the beginning you might realize 6 months down the line that some became unmaintained or no longer interoperate as well as they used to.
for all of these examples, React offers a vanilla way to do this, or you could use React + ECMAScript & polyfills to do this. there are definitely bolt-on libraries that do more with those but you can be fine with minimal dependencies on other things.
I feel like a lot of pain with React development is self-inflicted.
The only libraries I used aside from React itself were react-router (scars from dealing with the history API in a past life) and material-ui (not a designer.) react-router was a breeze, and I did end up spending a lot of time figuring out how to customize material-ui, but I still think it was worth not having to write my own components.
One thing that's key to this approach though is understanding the patterns your would-be dependencies use. For example, I did implement unidirectional state flow like in Redux. I just didn't use Redux. I also considered using a form library, but ended up just stealing some of its ideas.
Now where I do think libraries shine is on larger teams. Once you have a larger team, having documented ways of doing things, and the possibility of hiring people that already know them outweighs a lot of the costs of using libraries.
hooks, axios, html, reach-router.
my point is that if you start with the assumption that browser APIs are sufficient, there is a natural progression to your project and «taste» in supporting libraries to react
With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).
The closest to those for JavaScript is Nest[0]