Tester: The UI is wrong right here...
Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.
Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.
http://facebook.github.io/react/blog/2014/01/02/react-chrome...
You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality.
These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework.
Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is going to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice.
Contrast that with great software developers (and I've been fortunate to have worked with some really great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.
The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.
Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way.
They're a tool belt with tools that do one thing and do it really well. Frameworks are like having a tool belt with a hammer that also has a saw on the end but in order to use the saw you have to grab the screwdriver even if you're not actually using it.
That said, React is a "A Javascript Library for Building User Interfaces." And to me me it does feel more like a library than a framework.
It takes your data as an input and by some mechanism lays out a visual representation of it defined by your components render methods, being sure to update the visual representation as the data changes. The rest are implementation details.
I don't know who pointed it out, but I find that a good rule of thumb is to master at least one layer of abstraction below the 'current' one. So in the case of React, you'd first make sure you are proficient with javascript, the DOM, and how the web works.
If your point is to underline that using frameworks without understanding them is a bad thing, I fully agree. But arguing that 'these things' (frameworks) are bad just seems silly.
Clearly some clever people at Facebook found it useful to abstract certain things in a certain way, and many other people (some clever) like their approach. They've actively considered IanDrake's problem (in fact, they talk about this in their talk on React), and felt that their solution was good.
If I can build a performant client-side-heavy web-app in half the time because of React, I'm doing the client a service, not a disservice.
They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But that last 10%... its like pulling teeth. With tweezers. Covered in grease.
That last 10% is the thing you need done to successfully deliver the project but which the framework designers didn't consider.
In my experience you always run into that last 10%. The net result is that all those speed gains you realized early on are completely lost (and then some) because you're fighting with the framework.
So sure, understanding the framework might help you with that last 10%. But I personally think you're better served mastering JS, the DOM, and how the web works. Which really isn't that hard by the way!
And anyway, if frameworks were so great why are there so many? It seems like a new framework gets announced every week here on HN. The shear tonnage of frameworks alone makes me question their value[1].
Now if none of that can convince you, consider this; the company I work for got rid of all their framework programmers and replaced them with me and a couple other software developers who have experience building products without using frameworks. And they pay us more money than they paid the framework programmers. Why? Because we did more work with better quality in the first six months than those other guys could do in 2 years of gluing framework code together. That last 10% hit them HARD and cost them their damn jobs!
1: I do recognize that frameworks provide value. My argument is that they are way overused. Great for building working or semi-working prototypes in order to test an idea in the market. Terrible for building anything that needs to be continuously maintained.
I took issue mostly with the blanket statement that frameworks are bad, because I think there's a lot of variety. Backbone, for example, is so basic that it might be useful for 'master' programmers, whereas Rails is a monster framework that is a bitch to handle if you get to that 10%. And I'd argue React, which is more of a library, could be a very useful abstraction that leaves you free to do things your own way, or even replace it eventually. But I might be wrong about that! I'm not a master...
Also, I guess in the context of the framework/library-explosion it makes sense that you'd point out the problems with a little less nuance :). And it's a good reminder for me as a young framework-raised, self-taught whipper-snapper to make sure I become a master at my 'craft'.
And not just because it pays better.
Just raw DOM manipulations?
I feel like your argument is partially valid, but your argument also sounds like it effectively argues for pure Assembly. Anything ontop of that costs you a ton at the 10% mark. Now, i understand there's a difference between a Framework and a Language, but i hope you can understand my point.
I feel like you're going to one extreme, and arguing against another. Arguing opinionated frameworks with equal opinionated design seems odd to me.
Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye.
If it's cleanly written, with a framework that makes sense, isn't it far easier to maintain than raw JS? (Not specifically about React, just in general)
Disclaimer: I like React quite a bit. But i don't think you're "wrong", we just see things differently.
Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye.
The reason I don't believe you can write something cleanly with a framework and it be easier to maintain is that the framework is a black box of unknowns. So one option, as someone else has mentioned, is to try to fully understand that black box. But then you've just tied yourself to that framework. Wouldn't you be better served mastering the technology that the framework is written in?
1: jQuery proper. jQueryUI isn't too bad but is still a little more black box than I prefer. I really dislike jQuery Mobile for all the reasons I dislike frameworks.
The result of all this is code that is harder to maintain, even for those who know how to use said framework.
While I'm not against frameworks myself (in fact I argued in favor of them in this very conversation), I have become much more weary of them. In fact, after a brief affair with CoffeeScript I've even come to be more hesitant about using that or other 'transpilers', as I recently ran into the problem where I had to revert to plain js and I discovered that I'd lost some proficiency.
That said, it depends partly on the developers, and partly on the amount of structure the framework forces you into.
And that said, I suspect using a framework often serves more to alleviate managers' concern about maintainability than anything else.
There's one case where I would strongly suggest someone use a framework though, especially an opinionated one such as Rails. By following the Rails Tutorial by Michael Hartl, I learned a lot about best practices that I wouldn't have learned had I cobbled together a bunch of libraries. So for beginning developers, a framework might help them get started with their prototypes and whatnot.
Then again, maybe that worked for me because I can't help but want to look behind the curtain... I've certainly met my share of developers who never seen to wonder what's behind the magic.
If your average LOC is ever more than 200 lines or so, you've got a messy app.
Last year I got excited about NodeJS and started working with it quite heavily. Then I started to see holes - difficult debugging, so-so tooling for development, mixed bag of JS components, and so on. I then stepped back and realized that although it was interesting, and I can see it useful for some specialized server-side development, I don't see it as compellingly different than current alternatives (Rails, .NET, PHP, etc) to try to build a whole web app with it.
To extend your argument, I would state that frameworks are only about speeding up the initial creation of an application that fits into a narrow set of assumptions. Frameworks, by their very nature, capture a set of decisions by their designers about how an app should work (or behave). As long as your app fits nicely into this box and you can live with the downstream risk that maybe it won't one day, then go for it.
Ranting against frameworks represented by React is a strawman here. It doesn't include a router, nor a model layer, nor the traditional controller. It's a miracle that it's even compared to Angular and Ember, but I guess that's the extent of the power of View + solid declarative nature, so we'll take it as a compliment.
We also don't want to turn it into a huge framework, so if that's your only concern here, then please feel free to give it a try =).
Full stop right there and you're correct. I really prefer to limit code that looks like:
element.innerHTML = '<div>Do you really like content in your JS like this?<div>';