3 ms·

I really don't get what people mean when they say they're against frameworks. Your app that you're making with no framework...how are things structured? Do you

I really don't get what people mean when they say they're against frameworks. Your app that you're making with no framework...how are things structured? Do you just repeat yourself everywhere? Or do you really have a pseudo-framework that's implicit in the conventions that you use? What I'd like more than anything else is examples of substantial web apps written without a framework.

albertoleal 12y ago
I don't think that's what people meant. This is probably what they meant: "Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn" Source: http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/ http://www.breck-mckye.com/blog/2014/12/the-state-of-javascr...
- flipside 12y ago
  Shoutout for Ampersand.js which was mentioned in the article. The modularity is really nice for keeping things flexible so I can swap out parts as our app evolves. http://ampersandjs.com http://ampersandjs.com
- hyperpape 12y ago
  I should've pre-empted this, but I didn't. If you're gluing libraries together, it seems like you're sort of creating an ad-hoc framework. Is the difference just that you're making it up as you go along and you're not creating something that attempts the same kind of generality?
  - albertoleal 12y ago
    The general philosophy is that you're not wasting time fighting against the [monolithic] framework. In addition, in practice, one size doesn't fit all. For every project and team, you [and the team] have the flexibility to choose the libraries that would be effective for said project. Thus, the ad-hoc framework would generally be different for every project. In general, you [or the team] probably wouldn't re-invent the wheel, and you'll likely to find a decent library on npm.
  - zarriak 12y ago
    A major advantage to putting libraries together is making the code that is able to be the glue between the different libraries. It usually is the part that defines the structure of the app overall, allowing you create solutions to your needs that are not available to you in large frameworks. You can implement the same things in Angular or Ember, but you will be sacrificing choices that will result in the problems present in the author's article. The inherent formulaic approach lends itself to extending the use of things that worked in the code base to places they shouldn't be. This is significantly decreased when you are handling the libraries, because they force you to think on a more fundamental level of the approach you need to take. Take this basic idea of what an app does (I use code in this context to mean js that was written by you.) Input -> The code -> Output Frameworks: The code exists in all three areas, resulting in having to change all three areas of the code instead of one. Libraries: The code exists separate of the input and output, allowing one to make changes to any of the three areas without having to change much (if anything) in the way the code works. This (in theory and usually in practice) also makes testing easier to develop even if the code wasn't designed with testing in mind.
    - hyperpape 12y ago
      This only seems applicable to code that can be structured as a pipeline of data, which isn't many javascript apps.
z92 12y ago
The alternate of frameworks is libraries. Which gives you better overall control while still hiding the details.
wtbob 12y ago
> I really don't get what people mean when they say they're against frameworks. Your app that you're making with no framework...how are things structured? Do you just repeat yourself everywhere? So, there are frameworks and there are libraries. With a framework, you use the structure provided by the framework, and hook pieces of your code into it; with a library, you structure your code to your problem, and use libraries to provide functionality. Frameworks are generally easier to get started with: they provide a lot, and their pieces generally work well together. But inevitably, the day will come when you need to do something not envisioned by your framework, and then you're stuck: it can be arbitrarily difficult, painful and/or low-performance to do what you need. That last point is also worth mentioning: because a framework tries to be good at providing the same structure for a lot of different problems, it inevitably is a jack of all trades and a master of none. This can end up meaning poor performance, due to needing to call lots of functions to do simple things (imagine some hellacious Java framework with AbstractFactoryVisitorSingletons), or it can be a pain on the programmer, or both. Meanwhile, libraries are just that…libraries of code that the programmer can use to implement needed functionality. How he stitches them together is up to him. With a framework, your code lives within someone else's structure; using libraries, other people's code is called by yours. 'How are things structured?' However you want! Read http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than... for more, and http://www.evanjones.ca/frameworks-necessary-for-large-scale-software.html http://www.evanjones.ca/frameworks-necessary-for-large-scale... for an opposing view.

albertoleal 12y ago

I don't think that's what people meant. This is probably what they meant: "Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn" Source: http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/ http://www.breck-mckye.com/blog/2014/12/the-state-of-javascr...

flipside 12y ago
Shoutout for Ampersand.js which was mentioned in the article. The modularity is really nice for keeping things flexible so I can swap out parts as our app evolves. http://ampersandjs.com http://ampersandjs.com
hyperpape 12y ago
I should've pre-empted this, but I didn't. If you're gluing libraries together, it seems like you're sort of creating an ad-hoc framework. Is the difference just that you're making it up as you go along and you're not creating something that attempts the same kind of generality?
- albertoleal 12y ago
  The general philosophy is that you're not wasting time fighting against the [monolithic] framework. In addition, in practice, one size doesn't fit all. For every project and team, you [and the team] have the flexibility to choose the libraries that would be effective for said project. Thus, the ad-hoc framework would generally be different for every project. In general, you [or the team] probably wouldn't re-invent the wheel, and you'll likely to find a decent library on npm.
- zarriak 12y ago
  A major advantage to putting libraries together is making the code that is able to be the glue between the different libraries. It usually is the part that defines the structure of the app overall, allowing you create solutions to your needs that are not available to you in large frameworks. You can implement the same things in Angular or Ember, but you will be sacrificing choices that will result in the problems present in the author's article. The inherent formulaic approach lends itself to extending the use of things that worked in the code base to places they shouldn't be. This is significantly decreased when you are handling the libraries, because they force you to think on a more fundamental level of the approach you need to take. Take this basic idea of what an app does (I use code in this context to mean js that was written by you.) Input -> The code -> Output Frameworks: The code exists in all three areas, resulting in having to change all three areas of the code instead of one. Libraries: The code exists separate of the input and output, allowing one to make changes to any of the three areas without having to change much (if anything) in the way the code works. This (in theory and usually in practice) also makes testing easier to develop even if the code wasn't designed with testing in mind.
  - hyperpape 12y ago
    This only seems applicable to code that can be structured as a pipeline of data, which isn't many javascript apps.

z92 12y ago

The alternate of frameworks is libraries. Which gives you better overall control while still hiding the details.

wtbob 12y ago

> I really don't get what people mean when they say they're against frameworks. Your app that you're making with no framework...how are things structured? Do you just repeat yourself everywhere? So, there are frameworks and there are libraries. With a framework, you use the structure provided by the framework, and hook pieces of your code into it; with a library, you structure your code to your problem, and use libraries to provide functionality. Frameworks are generally easier to get started with: they provide a lot, and their pieces generally work well together. But inevitably, the day will come when you need to do something not envisioned by your framework, and then you're stuck: it can be arbitrarily difficult, painful and/or low-performance to do what you need. That last point is also worth mentioning: because a framework tries to be good at providing the same structure for a lot of different problems, it inevitably is a jack of all trades and a master of none. This can end up meaning poor performance, due to needing to call lots of functions to do simple things (imagine some hellacious Java framework with AbstractFactoryVisitorSingletons), or it can be a pain on the programmer, or both. Meanwhile, libraries are just that…libraries of code that the programmer can use to implement needed functionality. How he stitches them together is up to him. With a framework, your code lives within someone else's structure; using libraries, other people's code is called by yours. 'How are things structured?' However you want! Read http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than... for more, and http://www.evanjones.ca/frameworks-necessary-for-large-scale-software.html http://www.evanjones.ca/frameworks-necessary-for-large-scale... for an opposing view.