5 ms·

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here bec

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or they hold off on adopting the tech until they are shown The Right Way™ by someone else. The truth is, libraries and frameworks both end up being equally complex to work with, precisely because the problem of building large applications is inherently difficult. It all comes down to personal preference: Are you the type of person who is more likely to believe you can do something better than everyone else, or are you the type who is more likely to defer to those you believe to be better than you? Are you decisive or do you agonize over the smallest choices? Do you feel a compelling need to understand how everything works, or are you willing to implicitly trust other people's systems? I find it amusing that people who gravitate toward smaller libraries like Backbone.js and React.js rail against frameworks like Ember or Angular for being overly complex, heavy, and "magical", and then proceed to cobble together a Rube-Goldberg-esque system of disparate dependencies to achieve the same goals. When React first started getting popular all you read about was how simple the API was and how it was Easy to Reason About™. Fast forward to today and you need to have working knowledge of WebPack, ES6, Redux, immutable.js, Babel, and a bevy of other dependencies to be aligned with the React ecosystem's ever-evolving best practices. The exact same thing happened with Backbone.js and it will probably happen again with the next shiny new view-model library to ride the hype train. It's important that I point out, however, that none of this is necessarily a bad thing. Smaller libraries like React.js and Backbone.js encourage a cavalcade of innovation from which awesome things like Redux are born. But let's not pretend that this doesn't result in a heckuva lot of churn for the average developer whose job is to simply get shit done.

Retozi 11y ago
I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you. However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React. Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux. All other things are really not needed for most people, and if you do, you are facing problems so large, evaluation of libraries is a small fraction of the effort. It's more the mindset of people "I'm missing something great" that drives them crazy and into framework fatigue. (OMG server-side rendering, falcor, relay, immutable.js arrgggh) Usually, you are missing something you don't need, otherwise you would be looking for it actively.
- marknutter 11y ago
  > Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux. Quite easy for whom, exactly?
  - Retozi 11y ago
    For anyone that has the ability to pull off a project that needs seperate state management. It's really just a days worth of looking at the original flux, redux and other implementations and figure out what's best for your team and project. It doesn't take more energy / knowledge than to hack around patterns that don't perfectly fit your projects needs with the "everything included" frameworks.
  - meric 11y ago
    I see it as a set of web framework construction tools. You can roll your own isomorphic web framework in two weeks, whereas ember.js and angular.js took years to build. We build the framework that's suitable for our company. Once we got a thing going we use it for multiple projects.
woah 11y ago
You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.
- madeofpalk 11y ago
  Usually you're using ES6 because you can, because you're highly encouraged to use Babel to transform JSX.
- marknutter 11y ago
  > You describe ES6 as some kind of exotic dependency. To the non Silicon Valley / Hacker News crowd, it certainly is. And using ES6 means you need to make a choice about which transpiler to use, which build tool to use, etc. > Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default. Well known to who, exactly? Because the "well known default" as of a few months ago was Reflux, and before that it was Flux. Oh, and there's Relay and GraphQL. When's the "well known default" going to change again? I give it two months before everyone rushes to the next new gotta-have dependency. It's like reading Dr. Suess's The Sneetches.
  - daveidol 11y ago
    You're not wrong: things do change quickly in the JavaScript world. But have you actually been following this stuff very closely? "Flux" was never a "well-known default," because there was no single "Flux" library - only Facebook's little written guide and an implementation of the dispatcher (a small part of the overall Flux architecture). So, there were about 500 different implementations of "Flux" - none of which I'd say were ever considered a "well-known default" (the biggest ones - Reflux, Alt, Marty, Flummox, and Fluxxor - all have roughly between 1000 - 3000 stars on GitHub). Then, Redux came on the scene and became the first and only "well-known default". Several of the Flux libraries I just mentioned actually deprecated themselves and put up notices to use Redux instead. As of the time of this writing Redux has almost 13,000 stars on GitHub. Relay/Falcor are really part of an entirely different thing than React; they are about replacing the traditional REST API with an entirely new paradigm.
xiaoma 11y ago
>next shiny new view-model library to ride the hype train. If widespread use in production by Facebook isn't real world enough for you, then perhaps it's best to find a slower-moving part of the stack.
- marknutter 11y ago
  It amazes me how much the software industry is like the fashion industry. Do you honestly base your technology decisions on what brand names are attached to them?
  - xiaoma 11y ago
    It's not about brand name. It's about being proven in production use. This is why Google's brand doesn't mean much in Angular's case (since most of their own products do not use Angular).
    - marknutter 11y ago
      Your comment strikes me as incredibly naive. Angular was written to tackle the task of re-writing the front-end of Double-Click, by far their most profitable application. Google is putting a ton of resources into Polymer, which is powering more and more of their mission critical properties, so Angular hasn't had the benefit of being blessed by the wider organization as the one, true way of doing things. I think that's a good thing, frankly. The group-think coming out of Facebook is unnerving to say the least. You should step outside the Hacker News bubble and do a little research into just how widespread Angular usage is. You will find that it's staggering. Google's name means a lot, even if they haven't gone all in on using Angular for everything. Don't get me wrong, I think React is a fresh new take on web development, but when I see people say "because Facebook™" it makes me cringe, hard.
  - paulddraper 11y ago
    Software is (mostly) about function. Fashion isn't. When something functions on massive scale, it's commendable, and worth looking at.
overgard 11y ago
I don't know, I think you're over-characterizing this as a psychological decision. I tend to prefer libraries over frameworks for the simple reason that they're usually much quicker to learn and use (because they have a single purpose), and they don't box me into patterns I don't want or need. I wouldn't categorize that as like making me a control freak or untrusting of others design decisions, its a pretty pragmatic decision.
- paulddraper 11y ago
  I think your reasoning falls squarely into the GP's description.
  - overgard 11y ago
    I don't think that's really true. Not to put words in his mouth, but the GPs assertion seems to be that library vs framework tends to not matter much other than in what it says about the individual, whereas my assertion would be that choosing small focused libraries has nothing to do with ego or imposter syndrome or whatever, I just don't want to learn a massive chunk of code if I can learn a small chunk of code and get equal value.
    - paulddraper 11y ago
      "I tend to prefer libraries over frameworks...they don't box me into patterns I don't want or need" You're confident that you're able to identify what you want and need, and how to get there. You don't need help or strong direction. In contrast, I worry about making the naive choice, and I trust that others have thought about this a lot more than me. So I tend towards things that have built-in best practices/assumptions/guidelines, i.e. "box me in".
      - overgard 11y ago
        Fair enough, I hadn't really thought of it from that angle, but I can see the value there
seivan 11y ago
Exactly the reason I love Rails, even though I'm not a fan of Ruby. Choice paralysis or https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis It's really severe, but articles from DHH and Rails itself really really help with that. I can't really put enough emphasis how greatly that has helped me.
- droidist2 11y ago
  Sounds like you'd like Ember then.
  - seivan 11y ago
    That's what I thought, tried it. Didn't like it. In the end, it still has to click and having separate templates for logic isn't going to cut it. React does it right, I just wish React came in a package. Which I guess it sorta does now with Redux/Reflux.js and React-Router, etc.
mercer 11y ago
I think you're right, but your last paragraph is crucial. The reason I'm doing front-end development is because I enjoy it. I'm not doing it only to 'get shit done'. And part of that enjoyment means not always having to deal too much with other people's choices, because sometimes they feel like straitjackets. So as long as the client doesn't suffer from me making choices based on enjoyment, I'm going to use RethinkDB, React for the back-end, and roll out my own custom-built CMS if I so desire. Because I'm responsible enough to know when this is okay, and it's just hella fun to do. But yes, when in doubt lean towards the thing that has been tried and tested over your own (possibly disastrous) sources. But also no, the most I've learned has been by making terrible choices and having to figure things out, truly figure things out myself instead of relying on frameworks from the start. I mean, it's not like things will explode when we fail in the front-end world, generally speaking.
draw_down 11y ago
If you're a "just get shit done" person, fine, go use a framework. I've just been burned too many times. It's not about complexity per se, it's about use cases the framework designers did not envision beforehand. Soon as you're in one of those, your goose is cooked. If the framework just does what you want and gets out of the way then great. But in my experience the pain is not worth whatever benefit a framework provides.

Retozi 11y ago

I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you. However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React. Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux. All other things are really not needed for most people, and if you do, you are facing problems so large, evaluation of libraries is a small fraction of the effort. It's more the mindset of people "I'm missing something great" that drives them crazy and into framework fatigue. (OMG server-side rendering, falcor, relay, immutable.js arrgggh) Usually, you are missing something you don't need, otherwise you would be looking for it actively.

marknutter 11y ago
> Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux. Quite easy for whom, exactly?
- Retozi 11y ago
  For anyone that has the ability to pull off a project that needs seperate state management. It's really just a days worth of looking at the original flux, redux and other implementations and figure out what's best for your team and project. It doesn't take more energy / knowledge than to hack around patterns that don't perfectly fit your projects needs with the "everything included" frameworks.
- meric 11y ago
  I see it as a set of web framework construction tools. You can roll your own isomorphic web framework in two weeks, whereas ember.js and angular.js took years to build. We build the framework that's suitable for our company. Once we got a thing going we use it for multiple projects.

woah 11y ago

You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.

madeofpalk 11y ago
Usually you're using ES6 because you can, because you're highly encouraged to use Babel to transform JSX.
marknutter 11y ago
> You describe ES6 as some kind of exotic dependency. To the non Silicon Valley / Hacker News crowd, it certainly is. And using ES6 means you need to make a choice about which transpiler to use, which build tool to use, etc. > Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default. Well known to who, exactly? Because the "well known default" as of a few months ago was Reflux, and before that it was Flux. Oh, and there's Relay and GraphQL. When's the "well known default" going to change again? I give it two months before everyone rushes to the next new gotta-have dependency. It's like reading Dr. Suess's The Sneetches.
- daveidol 11y ago
  You're not wrong: things do change quickly in the JavaScript world. But have you actually been following this stuff very closely? "Flux" was never a "well-known default," because there was no single "Flux" library - only Facebook's little written guide and an implementation of the dispatcher (a small part of the overall Flux architecture). So, there were about 500 different implementations of "Flux" - none of which I'd say were ever considered a "well-known default" (the biggest ones - Reflux, Alt, Marty, Flummox, and Fluxxor - all have roughly between 1000 - 3000 stars on GitHub). Then, Redux came on the scene and became the first and only "well-known default". Several of the Flux libraries I just mentioned actually deprecated themselves and put up notices to use Redux instead. As of the time of this writing Redux has almost 13,000 stars on GitHub. Relay/Falcor are really part of an entirely different thing than React; they are about replacing the traditional REST API with an entirely new paradigm.

xiaoma 11y ago

>next shiny new view-model library to ride the hype train. If widespread use in production by Facebook isn't real world enough for you, then perhaps it's best to find a slower-moving part of the stack.

marknutter 11y ago
It amazes me how much the software industry is like the fashion industry. Do you honestly base your technology decisions on what brand names are attached to them?
- xiaoma 11y ago
  It's not about brand name. It's about being proven in production use. This is why Google's brand doesn't mean much in Angular's case (since most of their own products do not use Angular).
  - marknutter 11y ago
    Your comment strikes me as incredibly naive. Angular was written to tackle the task of re-writing the front-end of Double-Click, by far their most profitable application. Google is putting a ton of resources into Polymer, which is powering more and more of their mission critical properties, so Angular hasn't had the benefit of being blessed by the wider organization as the one, true way of doing things. I think that's a good thing, frankly. The group-think coming out of Facebook is unnerving to say the least. You should step outside the Hacker News bubble and do a little research into just how widespread Angular usage is. You will find that it's staggering. Google's name means a lot, even if they haven't gone all in on using Angular for everything. Don't get me wrong, I think React is a fresh new take on web development, but when I see people say "because Facebook™" it makes me cringe, hard.
- paulddraper 11y ago
  Software is (mostly) about function. Fashion isn't. When something functions on massive scale, it's commendable, and worth looking at.

overgard 11y ago

I don't know, I think you're over-characterizing this as a psychological decision. I tend to prefer libraries over frameworks for the simple reason that they're usually much quicker to learn and use (because they have a single purpose), and they don't box me into patterns I don't want or need. I wouldn't categorize that as like making me a control freak or untrusting of others design decisions, its a pretty pragmatic decision.

paulddraper 11y ago
I think your reasoning falls squarely into the GP's description.
- overgard 11y ago
  I don't think that's really true. Not to put words in his mouth, but the GPs assertion seems to be that library vs framework tends to not matter much other than in what it says about the individual, whereas my assertion would be that choosing small focused libraries has nothing to do with ego or imposter syndrome or whatever, I just don't want to learn a massive chunk of code if I can learn a small chunk of code and get equal value.
  - paulddraper 11y ago
    "I tend to prefer libraries over frameworks...they don't box me into patterns I don't want or need" You're confident that you're able to identify what you want and need, and how to get there. You don't need help or strong direction. In contrast, I worry about making the naive choice, and I trust that others have thought about this a lot more than me. So I tend towards things that have built-in best practices/assumptions/guidelines, i.e. "box me in".
    - overgard 11y ago
      Fair enough, I hadn't really thought of it from that angle, but I can see the value there

seivan 11y ago

Exactly the reason I love Rails, even though I'm not a fan of Ruby. Choice paralysis or https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis It's really severe, but articles from DHH and Rails itself really really help with that. I can't really put enough emphasis how greatly that has helped me.

droidist2 11y ago
Sounds like you'd like Ember then.
- seivan 11y ago
  That's what I thought, tried it. Didn't like it. In the end, it still has to click and having separate templates for logic isn't going to cut it. React does it right, I just wish React came in a package. Which I guess it sorta does now with Redux/Reflux.js and React-Router, etc.

mercer 11y ago

I think you're right, but your last paragraph is crucial. The reason I'm doing front-end development is because I enjoy it. I'm not doing it only to 'get shit done'. And part of that enjoyment means not always having to deal too much with other people's choices, because sometimes they feel like straitjackets. So as long as the client doesn't suffer from me making choices based on enjoyment, I'm going to use RethinkDB, React for the back-end, and roll out my own custom-built CMS if I so desire. Because I'm responsible enough to know when this is okay, and it's just hella fun to do. But yes, when in doubt lean towards the thing that has been tried and tested over your own (possibly disastrous) sources. But also no, the most I've learned has been by making terrible choices and having to figure things out, truly figure things out myself instead of relying on frameworks from the start. I mean, it's not like things will explode when we fail in the front-end world, generally speaking.

draw_down 11y ago

If you're a "just get shit done" person, fine, go use a framework. I've just been burned too many times. It's not about complexity per se, it's about use cases the framework designers did not envision beforehand. Soon as you're in one of those, your goose is cooked. If the framework just does what you want and gets out of the way then great. But in my experience the pain is not worth whatever benefit a framework provides.