[hardwaresofton]

At this point I'm sure I and others sound like a broken record, but if you're new and just jumping into frontend component-based frameworks, please don't start with React.

There are simpler ways to get reasonably fast re-usable components on your project that introduce less accidental complexity.

Carefully consider which thing you actually need:

- A view library that uses components as the main building block (this usually means you already have other concerns like data modeling and routing taken care of)

- A full SPA framework (which people often get from the react ecosystem, i.e. React + Reflux/Redux/etc + React-Router)

Based on which one you need, there are other simpler (in the case of view libraries), and more coherent (in the case of full framework) choices.

[rohannair]

React is a view framework, and knowing the internals of React is a completely unnecessary set of knowledge for the majority of developers using it to build products with.

[hardwaresofton]

As with anything, the longer you use a library, the more you must know at least some of it's internals to use it efficiently/axiomatically/well. Even something small like the class/className attribute thing is an implementation detail that leaked through, which will bite and likely confuse a beginner for 3 seconds if they didn't throughly read the docs.

Other libraries don't have that problem (because they didn't accept that trade-off in that fashion).

IMO Libraries that beginners should be shown should not be ES2015-in-every-example, and introducing transpiled DSLs for generating DOM elements.

[simooooo]

I still love knockout. A simple view layer on top of whatever other architecture you want. Has worked really well for me for years.

[hardwaresofton]

Yep! One of my favorites (I didn't mention it because I didn't want to make it seem like I was just trying to push people towards another framework).

KO also has components now, and they work super great. Also, while bigger frameworks like Ember (which I love) are just starting to figure out and cement how they work with engines (dynamically loaded chunks of your ember app), KO supported async loading of components with RequireJS so long ago.

[ivanr]

Perhaps you're right, but it would be useful if you mentioned those other choices here.

[hardwaresofton]

Sorry I actually purposefully didn't mention them because I didn't want it to seem like I was just trying to push my own favorite choice.

Here are some options:

Component libraries -------------------

1) KnockoutJS (just data-binding, quite possibly the simplest I've seen)

2) Vue.JS (More complex, but one of the best sets of docs I've seen, fits in with the DOM model extremely well, few hacks, though I would have loved a simpler data-binding system)

3) Mithril.JS (super small, super fast, very simple. Transpilation tradeoff, it makes you just write the DOM as a JS function with elements like `m('div',[...])`. Have yet to use this one for a large project, but will very soon. Also has a little bit more support for the other thing you might need for a Single Page App.

Full fledged frameworks -----------------------

1) Ember (has been around a super long time, changes fast which is good and bad, and is great for large projects because it has a solid set of conventions)

[ivanr]

Thanks for coming back some days later to answer my question!

[hardwaresofton]

No problem! Apologize for the delay I didn't see the responses till much later. There are more obviously lots more options, but those are my go-tos for now (I try to kick the tires on new libraries/frameworks as often as I can).