6 ms·

As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server de

by dkarl 10y ago

As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it can be done as a library than as a framework. We look for libraries that humbly strive to coexist with whatever other libraries we need. The few times I've dipped into web UI Javascript, I've felt like the developers of UI "frameworks" share this mindset much more than the people using their work; often they'll explicitly point out that the tool they've built (such as backbone.js) is a library rather than a framework, while the people recommending it to me will say "no no, it's a framework," meaning "no no, it's way better than just a library." Is that an expression of a real difference between back-end and web UI code, or is it just different phases in the tide of opinion?

weberc2 10y ago
I agree. I program in quite a few languages, but Go is my favorite when it comes to a low-bullshit ecosystem. There are probably too many web frameworks, but the standard HTTP library seems to have the bulk of the marketshare.
morgante 10y ago
I'm pretty sure you're just playing with words here. One of the most common complaints is that the biggest web tools are libraries, not frameworks. React, for example, is very emphatically not a framework. To develop any reasonably sized application, you need to bring in a number of other libraries as well (such as Redux and/or Apollo).
- dkarl 10y ago
  It isn't just words — the words reflect people's expectation that a framework determines quite a lot about your design and approach. It's a system and a way of programming you assimilate into. A library tries to help you do something while dictating as little as possible about your overall application design. I think it's very interesting that even though the expert and experienced programmers who create things like backbone.js and React have openly and explicitly designed them not to be frameworks, people continue to call them frameworks, and not disparagingly. There seems to be a huge appetite for frameworks. From the outside (and definitely projecting my own inexperience) I would guess that a lot of people feel lost architecting a web UI from scratch. They don't want building blocks. They want a way, a path to follow. A lot of server programmers felt the same way twenty years ago. Adopting a framework meant giving up freedom that they didn't want in the first place because they didn't know what to do with it. But I'm coming at it from a very outside/inexperienced perspective, so I feel like I should leave it as a question rather than a comment. What do you think? Why are frameworks considered such a good thing in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?
  - morgante 10y ago
    I think your entire comment is built on a false pretense that popular libraries are called "frameworks." I have never once heard an experienced JavaScript programmer call React a framework. It's objectively not. To build any reasonable application you'll also have to choose, at the very least, a state management utility as well. That being said, I'm sure there are beginners who call React a "framework" but that can easily be explained by the simple fact that they are beginners: they don't really understand what React is or even what the differences between libraries and frameworks are. They assume any stack has to be built in some sort of framework, so React is that "framework."
  - amirouche 10y ago
    First you can use reactjs alone without a flux architecture. > Why are frameworks considered such a good thing The only thing nice about framework is that they make the main workflow obvious. But things becomes scary when you walk on the wild side (backed by experience with Django and Django RESTframework) The problem with reactjs is that facebook was using reactjs and its "architecture" for big apps and now they try to make it work in a more general context. > in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect? Backbone is framework, saying it's a library because you can use only the collection model and use whatever method you want to fetch your data or whatever template language or bind events yourself is like saying you can replace the URL routing or template language of Django on your own. Doable but not recommended.
amirouche 10y ago
There is a clear distinction between a framework and library. AFAIK a library is focused to solve a particular problem for instance routing, data validation, i18n, state management, view rendering (like templates systems), data models etc... On the other hand framework try to tackle a set of related problems into a coherent/logical workflow. For instance there is not a single library that can handle by itself the issue of isomorphic apps. Angular is a framework, reactjs is a library but http://reactboilerplate.com/ http://reactboilerplate.com/ is framework using reactjs. I think backbone is framework not a library it tackles several issues (class system, views, and middle end) and it does it badly but that's a topic of ~another post~ the past. Historically Javascript community has favoured the do-it-yourself framework hence or because there is a lot of libraries you can choose from or because the needs of everyone are so different that's it's difficult to create a miningful framework. Mind the fact that Google previous "framework" named Google closure was a stdlib kind of framework compared to the competition of MV* framework like emberjs or angular it did not force a given workflow.

by dkarl 10y ago

weberc2 10y ago

I agree. I program in quite a few languages, but Go is my favorite when it comes to a low-bullshit ecosystem. There are probably too many web frameworks, but the standard HTTP library seems to have the bulk of the marketshare.

morgante 10y ago

I'm pretty sure you're just playing with words here. One of the most common complaints is that the biggest web tools are libraries, not frameworks. React, for example, is very emphatically not a framework. To develop any reasonably sized application, you need to bring in a number of other libraries as well (such as Redux and/or Apollo).

dkarl 10y ago
It isn't just words — the words reflect people's expectation that a framework determines quite a lot about your design and approach. It's a system and a way of programming you assimilate into. A library tries to help you do something while dictating as little as possible about your overall application design. I think it's very interesting that even though the expert and experienced programmers who create things like backbone.js and React have openly and explicitly designed them not to be frameworks, people continue to call them frameworks, and not disparagingly. There seems to be a huge appetite for frameworks. From the outside (and definitely projecting my own inexperience) I would guess that a lot of people feel lost architecting a web UI from scratch. They don't want building blocks. They want a way, a path to follow. A lot of server programmers felt the same way twenty years ago. Adopting a framework meant giving up freedom that they didn't want in the first place because they didn't know what to do with it. But I'm coming at it from a very outside/inexperienced perspective, so I feel like I should leave it as a question rather than a comment. What do you think? Why are frameworks considered such a good thing in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?
- morgante 10y ago
  I think your entire comment is built on a false pretense that popular libraries are called "frameworks." I have never once heard an experienced JavaScript programmer call React a framework. It's objectively not. To build any reasonable application you'll also have to choose, at the very least, a state management utility as well. That being said, I'm sure there are beginners who call React a "framework" but that can easily be explained by the simple fact that they are beginners: they don't really understand what React is or even what the differences between libraries and frameworks are. They assume any stack has to be built in some sort of framework, so React is that "framework."
- amirouche 10y ago
  First you can use reactjs alone without a flux architecture. > Why are frameworks considered such a good thing The only thing nice about framework is that they make the main workflow obvious. But things becomes scary when you walk on the wild side (backed by experience with Django and Django RESTframework) The problem with reactjs is that facebook was using reactjs and its "architecture" for big apps and now they try to make it work in a more general context. > in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect? Backbone is framework, saying it's a library because you can use only the collection model and use whatever method you want to fetch your data or whatever template language or bind events yourself is like saying you can replace the URL routing or template language of Django on your own. Doable but not recommended.

amirouche 10y ago

There is a clear distinction between a framework and library. AFAIK a library is focused to solve a particular problem for instance routing, data validation, i18n, state management, view rendering (like templates systems), data models etc... On the other hand framework try to tackle a set of related problems into a coherent/logical workflow. For instance there is not a single library that can handle by itself the issue of isomorphic apps. Angular is a framework, reactjs is a library but http://reactboilerplate.com/ http://reactboilerplate.com/ is framework using reactjs. I think backbone is framework not a library it tackles several issues (class system, views, and middle end) and it does it badly but that's a topic of ~another post~ the past. Historically Javascript community has favoured the do-it-yourself framework hence or because there is a lot of libraries you can choose from or because the needs of everyone are so different that's it's difficult to create a miningful framework. Mind the fact that Google previous "framework" named Google closure was a stdlib kind of framework compared to the competition of MV* framework like emberjs or angular it did not force a given workflow.