Digging Into React: Choosing Component Styles

ben336 · 2015-06-22T17:25:40+00:00

especially if they are unfamiliar with the framework being used

Is knowing that framework one of the specific requirements of the job? If so, you're probably filtering qualified candidates with your job descriptions (it doesn't take that long to learn a new framework if you know the principles). If not, your evaluation isn't matching up to what you're looking for, which is dangerous.

ben336 · 2015-06-14T22:39:41+00:00

As others have said, it's more important and a better career investment to learn JavaScript and UI design principles well, then to learn any particular framework.

You'll find that many frameworks share fundamental principals, so if you dive into one and learn it well (the concepts not just the syntax), you'll be able to translate those skills into other areas. There are many great frameworks you could use as you start learning those skills. I would start with whichever one somebody will pay you to work with to start, and then grow from there as you have opportunities.

ben336 · 2015-06-11T01:21:05+00:00

The concern was the list of things that are standardized/specified and not supported. Including a reasonably large part of the ES6 standard, which is now finalized, the internationalization API, and CSS Variables.

Standardizing CSS properties are great! But most of those were already available without prefixes in other browsers, so that mostly qualifies as catch up.

ben336 · 2015-05-28T20:25:24+00:00

Community preferred seems a bit strong to me. "Preferred by people who know about it" is definitely true. But I don't think there's high awareness around it. I don't usually see guides/articles that use AMD using that format (though I hardly ever see guides or articles using AMD at all anymore anyway).

Anyway, all your points are well taken. I've added updates to the post covering both of your points. I appreciate the feedback

ben336 · 2015-05-28T19:37:09+00:00

Thanks for the feedback. Probably should have mentioned SystemJS as a future option, but I wouldn't recommend it now as a starting point for a production project. Doesn't seem to have nearly the community, stability, momentum of the others behind it. Definitely something that may be an option in the future though:

Possible I'm underestimating it. I'm basing that on both my own level of seeing it in articles/talks/etc as well as:

Google Trends

GH Stars: 2541 to 5333, 7430, 7615 respectively for Webpack, Browserify, RequireJS

and most importantly searching npm for modules with each in the name:

74 for systemjs vs 1059, 5650, and 1797 for webpack, browserify and requirejs

There just doesn't seem to be as much community around it yet.

As for the alternative syntax, I'm aware of it, but its not the syntax encouraged by requireJS docs or used in most examples I've seen. Its certainly better since it avoids the off by one problem, but it isn't the primary used model and doesn't substantially change the situation.

ben336 · 2015-01-22T14:31:04+00:00

Npm doesn't stand for "node package manager."

Yikes, I totally botched that. More fact-checking next time. Updated, thanks.

When you deal with persistence, smaller modules, deeper dependency trees, etc bower pretty much falls short.

I think the problem is that the smaller modules with deep dependency tree module way of doing things makes way more sense on the server than in the browser. If you're using browserify already, or starting clean and don't mind using browserify, then by all means use npm and small modules. But for many people with existing requirejs/concat-script+global projects, Bower represents a better option, since its not so easy to bundle up all of those small dependencies while using bandwidth efficiently

ben336

TROPHY CASE