I have a very different perspective than the author.
I've considered Libraries to be the pieces of code that let us 'paper over browser inconsistencies' to be things like jQuery. Sure, they also gave us some useful tools and plugins to accomplish tasks, but on the core purpose was to be able to write simple javascript code for common functions and have parity across all the major browsers.
Frameworks, I view at as code organization and paradigm tools. They create a more consistent structure for a group of developers to work on a single project. It aids in creating an MV* or other similar paradigm that a team can work within. Even outside of a team environment, Frameworks give you a ... framework, of how your app should be built, rather than just creating your own structure as you go along.
This is the reason why there are so many frameworks vs. libraries. Once you've chosen a library to handle browser inconsistency, as the author mentioned, barely an issue anymore, there is an endless possibility as to how your app should be structured. Some people like two-way data binding, some don't. Some people need extreme DOM performance of leveraging the virtual DOM, others hate the idea of having their html closely bound to their javascript (and framework as often the case).
I think yours is the traditional take on frameworks vs. libraries, so you're not alone. We have a lot of frameworks in JavaScript because we're still expanding and exploring the space where they can work. Eventually I think we'll settle on a smaller number of frameworks, but even so I doubt we'll see the level of consolidation that happened with libraries and jQuery.
I concur. I remember the days when there was explosion of Java framework last time, though the Java community at the time doesn't seemed to mind (they seemed to like choices) :-). There are some voices that complains of too many choices, but I think people generally agree there can be no One True Stack (TM).
As for preferring library over frameworks, sure why not. There are tons of reason to be able to do things other than the way that is described by a framework, but when you start to have teams bigger than 20, of different time zones, with varying skill level (important point here), having a prescribed way to do things may not be such a bad thing. There will be time to break the rules of the framework, but hopefully your choice of framework is good enough that it should only be less than 10% of the case.
To this, I can say that despite the failing of AngularJS, some teams just cannot live without it. Its very prescriptive to the point that people who a very good at Javascript may find it repulsive. But those prescription are just too robust for some team to abandon it and go for a more performant framework.
And there is a lot of companies that can't hire Google level developers. These people may not know Javascript enough, but are okay as long as there are good prescriptive example of how to do things. They should still aspire to be good at Javascript (or any language at that...), but sometimes that seems to be too much to expect for the portion of them. Sure, this is not ideal, but you have to remember, there are a lot of places in the world that IT is a cost center.
I disagreed with the author as well when I read this - libraries are a hodge podge of piecing stuff together, and when developers are left to their own devices, they often create an unreusable monster. Onboarding new developers also becomes harder due to it taking longer to understand the fundamental structure - there is not too much prior experience that can be drawn on to understand lower level logic.
You have a point, from my perspective though the difference between a light-weight framework like Backbone and one like Ember is almost as big as the difference between say Backbone and jQuery.
Don't throw the baby out with the bathwater. Sure JS frameworks are often unnecessary, that doesn't mean they aren't solving real problems.
The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago. The amount of experience and expertise that is being codified in (for example) Ember.js is fantastic and will allow you write much richer web apps in far less code than trying to achieve the same functionality with it.
Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.
> Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.
That pretty much sums up the article's stance on frameworks. Even with reusable components, there will be a need for frameworks because just using JS/CSS/HTML directly, one would essentially be creating a framework with each application. There are standard things that a framework encapsulates in any language or target environment which will be unnecessarily repeated and sub-optimally created if one decided to start from scratch on every application. I think the author misses this part completely. While learning a framework enough to start making things in it may take a day or two, creating a new framework because one hate using frameworks will take days to weeks and still likely leave desiring functionality they had not thought of or had implemented badly.
> The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago.
I'd dispute that. 10 years ago we had pretty brilliant browser based apps. They just happened to be using flash or Java applets whereas now they're using javascript.
I've been seeing the term "web app" a lot lately. Not exactly sure why. Is a web app different from a website? I guess so probably maybe? I'm not really sure.
"React isn't a framework, it's a library!" There I said it!
Jokes aside, React provides a Virtual DOM which isn't available natively. I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore. Until then, React is the best way forward. There are plenty of thin VDOM libraries (some even more efficient than React) out there but the joy of working with code written as composable Components outweighs efficiency (I'm sure those libraries would fare far worse in benchmarks if composability is put into the equation). Couple this with a library like Om/Reagent and you get FP (code as data)+immutability handed to you on a silver platter.
Without the "right" libraries you introduce a lot of incidental complexity into your application development lifecycle.
> "React isn't a framework, it's a library!" There I said it!
React is a framework though, for the most part it calls you(r components), you don't call it outside of the original binding. It's not a huge one, but it's still one.
> I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore.
Browsers already batch changes and defer recomputations as much as they can. They can't significantly improve the model because it requires a different abstraction which is not available under the existing DOM.
Also, you can use a VDOM without using React and its component, several VDOM-only pure=js libraries have sprouted up e.g. https://github.com/Matt-Esch/virtual-dom (the basis for elm-html, and the Mercury react-like framework)
Well, the virtual DOM is a great concept regardless - storing diff information on JavaScript is a great optimization, even if browsers eventually optimize browser rendering speeds, one will still be able to squeeze more with this & benefitting from that optimization.
None of the upgrades in ES6/ES7 obviate the need for frameworks. Maybe some libraries are made redundant, but frameworks address more interesting abstractions that a general language probably shouldn't cover anyway. Frameworks seem to adopt more opinions about implementation, and help unite a team over a set of ideas, and enable them to move faster and reason about similar problems in similar ways. Hopefully that team has picked a framework that is also well-suited towards the problem they're solving.
As a user of Angular, Backbone, and React (not all at the same time!), I feel like their largest benefit to me is in providing application structure -- good because as it has been said, if you aren't using a framework, you are writing your own.
I don't really see how any of the 3 items under the article's "So what do we need now?" will provide that benefit.
Not just structure, they enforce application architecture, something that you often miss until it's too late if you just get busy gluing together lots of npm modules to build your application.
I think it has to do with the way the developer approaches the problem, their background, and their preferences.
Personally I'm with you, I enjoy a small, isolated, component based approach where each component follows the unix philosophy. I think this lets you write the most performant and resuable code. Also, I think when following this style, it limits the scope of your dependences, which is another big plus. For instance, you might need a library for crypto, but you won't need one for doing your authentication system, and you won't have massive modules for handling auth that would come from a framework getting compiled into your production code.
But when you go this route you do have to make a lot of "right" decisions that are made for you when using a framework. Also, I think a lot has to do with deadlines and developer speed, it initially takes a little longer to write good standalone components that are reusable, and just grabbing some framework will help get shit done in the short term, but might have the same detriments as technical debt in the long run.
Yeah that's my attitude too, Ember scared me away because of the kitchen sink approach and the fact it introduced lots of new abstractions that I hadn't seen proven elsewhere, and that didn't really seem to me to be what I would be expecting from a Web framework.
Something like React bothers me far less as it smaller, less imposing, and solves real problems I've seen with other frameworks (for example by pushing clear/consistent/simple communication paths).
The only js framework I'm aware of that could accurately be described as trying to solve everything and the kitchen sink is ExtJs, which includes a wide widget library, and is very opinionated about how you interact with the DOM. Ember is is not a "kitchen sink" framework, and Backbone is certainly not.
I've found that even if you start with the "basics", like the author describes, that you'll end up finding that you repeat the same types of tasks repeated. So, you refactor and make functions that simplify common actions. After a while, I guarantee you that your code will look a lot like a framework.
Frameworks are created because they make solving certain types of problems easier and reduce code duplication, whether you use someone else's or your own.
A framework has control of the application by default and gives control to your code at designated points, to perform some computation and then return control to the framework.
A library takes control of the application when/where your code calls it, performs some computation and then returns control to your code.
A library is a way to reuse code; a framework is a way to reuse application structure/design and control flow.
The pain points of frameworks are well known at this point, I guess the question is given a really good set of high-level libraries, could you be as productive as you are using a framework? Maybe not at first, because you have more design choices to make. But later, you have less of other people's design choices restricting you.
> The problem is that now you have two systems to learn, HTML+CSS+JS, and the framework
Besides that there are 4 things listed there, not to mention how each interacts with the other, this is not a problem. If you shy at learning an additional thing, you should get out now.
That's not to say you shouldn't strive to reduce complexity and dependencies, that's a laudable and useful goal. But it's my personal opinion that every programmer out there should know at least a handful of languages, concepts, paradigms or frameworks that they don't like or have no use for--it's the same basis of learning more from failure than success.
That being said, I sincerely disagree with the assertion of the article, if on nothing more than the abstraction argument. The abstractions of jQuery have saved me so much time over the years with systems that work great in the latest and greatest browser, and work well enough, possibly with minor tweaks, in older browsers. Rewriting browser detection junk and making sure each control mostly works independent of browser and engine would be a much larger waste of my time than learning three or four js frameworks.
I see his argument about being primarily about the future, that as the standards fill in the gaps investing in libraries will become less of an attraction.
Don't forget he was part of the REST/ROA group who were belittled when they said that Web standards were an alternative to the ridiculous number of Web Service standards and he was quite right in that case.
I agree with you wholeheartedly. I just recently started blogging exclusively on how to build dynamic without javascript framework @ http://pothibo.com
Solutions exist outside the scope of JS framework. We only need to take a minute to analyze them. It's not a popular decision to avoid JS frameworks but I believe some criticism of the current solutions available is in order.
It's not only the frameworks. Working with JavaScript has become ridiculously complicated. I remember when I started developing JSF applications. You had to learn about application servers, servlets, Spring, MySql, Maven, Hibernate JSF, JSP and the various JSF extensions before you could even start working. JavaScript now has become almost the same with Bower, NPM, Angular MongoDB Grunt, Compass, Jade and whatnot. Nowadays, when I start a project I try to keep it as simple as possible because
a) Todays technology is deprecated tomorrow
b) When someone joins I'm the one who'll have to teach them
The number of tools has increased, but I think JS development has actually been simplified in some cases. This is largely due to the rise in popularity of rich clients talking to simple backend APIs. In older web projects JS always felt like an afterthought. Dependencies were managed totally by hand and your scripts were scattered throughout the backend templates. If you needed to do anything at all with your front-end code at build time, you had no choice but to glue some hacky solution onto the existing build process. Client and server were all mixed together, and it was painful.
Starting a project today, I can build a client in Javascript, hook it up to an API, and I'm done. NPM and Browserify make dependency management and builds a breeze. There's very little friction in the development workflow because the front-end build process it totally separate from the server. I make a change, save it, reload the page and I see my changes live without even running a server locally. Even PHP's deployment story isn't that simple.
It's true that the initial setup is more complicated than simply downloading jQuery and plopping it into an existing project, but if you have the option of separating your client and server code, it really simplifies things overall.
It's not just about a framework featureset, frameworks also provide convention and structure. Convention and structure are a problem whether or not you choose to use a framework.
Frameworks give us a language to speak to each other about the nuts and bolts of our application. This means new developers can get ramped up quickly (provided they understand the framework) and there is a common body of best practices that can be referenced when faced with difficult problems. There's a lot of value in that.
Theoretically you are right, but in practice you spent more time with the framework and how the "best practices" work, as with you application.
Most problems are simple, but to solve them in a framework, you have much todo.
And when you understand and use everything "the right way", the new Version of the Framework arrive -> see angualar v2.
A new Framework with a new underlying language (WTF?)
Best practices work without frameworks too, you have only to define them and communicate them with your co-coders.
Since requirejs with the modularity and different build tools, i feel no need for a huge framework.
I pick the libraries i need and build parts of the application into modules, since the communication run with events it is clean, structured and has a clear defined API.
"This means new developers can get ramped up quickly"
Agreed that is an advantage of frameworks, but is it not more of an argument for a mature framework like Rails, rather than the current JS frameworks which appear and become (essentially)obsolete/niche in a year or two?
People also said this when HTML5 was on the rise—pure JS, no runtime but the browser! Of course, it turns out engineering DOM-manipulating applications in a responsive way is really hard.
These are the core benefits of frameworks:
1. Standard code style.
2. There's only one way to do it (ideally).
3. Modularization.
4. Unit testing.
5. A realistic standard library for async/concurrent computation.
Angular, for instance, provides dependency injection and $scope/$digest. It would be pretty ridiculous to attempt to replicate those benefits until AT THE VERY LEAST Object.observe has solidified in terms of support. And even then, you're on your own in terms of mocking, in terms of communication between different modules, in terms of libraries you can drop in without dragging in a framework itself.
I'm appreciative of the attitude, but it's quite simply not a reality for people who don't want to invest in establishing their own patterns—in effect, writing a framework. With a framework, people can sit down and use the engineering techniques they've learned from other areas of CS and write an application without being bogged down in terms of figuring out how to write a high-performance single-threaded web app in a language without modules, integers, futures (or other similar async abstractions), calendar widgets.
Try going without JQuery for a day and see how much duplicate code you write.
Then, multiply yourself times a team of 10.... good luck.
You missed out on the biggest core benefit of frameworks: battle tested code for a very large chunk of your application without having to re-invent it all from scratch. Frameworks give you a stable foundation to build on.
There is actually a tool[1] that will provide the right subset of polyfills to the specific browser. However, you do need to specify the list of polyfills you use in your code.
The default included polyfills tend to cover most things in my experience. I haven't had to worry about if a feature exists in IE8 or if we're polyfillng it for a while now, it's great.
I think one of the biggest problems with the morass of client side code in many large code bases is that it's written, by and large, by engineers who are trained and focused on the shared-nothing world of http server side development. The art of managing state, and the goal of a stateless application is lost on you if you've never had to mentally run a program that runs longer than a few seconds. Yes, there are many fad frameworks. But I totally disagree that the answer is "fewer frameworks, more raw js." I think the answer is building tools to help better manage state (eg React), and over time strengthening the skills of your average "full stack" web engineers from 75% server side 25% client side to a more 50/50 split.
This post is just pushing web components / polymer with a controversial title right? I don't think it's production ready yet though (slow polyfills), and there's some differing opinions on how web components should be built.
The author of this article completely ignored all of the features that actually make people use Ember.js. Router, naming conventions, project structure, container to manage objects. It's possible that in the future Ember.js will use plain HTML components and JS features like Object.observe, but it won't mean that suddenly its code will shrink to 1kB, because it's not all there is to the framework.
My summary of that text: "I don't know how frameworks work, so let's not use them".
In some ways, browsers are as fragmented as ever. Everyone loves to forget IE, but the last I checked IE8 was #3 in sales in our shop. Throw in a little jQuery and we never have to worry about a lot of things. Polyfills are nice, except that browsers are still experimenting, and plenty of people aren't mindful of that fact and it's not uncommon to visit sites that don't work properly on a browser other than Chrome. A sad state of affairs, but a reality nonetheless
[+] [-] pedalpete|11 years ago|reply
I've considered Libraries to be the pieces of code that let us 'paper over browser inconsistencies' to be things like jQuery. Sure, they also gave us some useful tools and plugins to accomplish tasks, but on the core purpose was to be able to write simple javascript code for common functions and have parity across all the major browsers.
Frameworks, I view at as code organization and paradigm tools. They create a more consistent structure for a group of developers to work on a single project. It aids in creating an MV* or other similar paradigm that a team can work within. Even outside of a team environment, Frameworks give you a ... framework, of how your app should be built, rather than just creating your own structure as you go along.
This is the reason why there are so many frameworks vs. libraries. Once you've chosen a library to handle browser inconsistency, as the author mentioned, barely an issue anymore, there is an endless possibility as to how your app should be structured. Some people like two-way data binding, some don't. Some people need extreme DOM performance of leveraging the virtual DOM, others hate the idea of having their html closely bound to their javascript (and framework as often the case).
[+] [-] dmethvin|11 years ago|reply
[+] [-] fadzlan|11 years ago|reply
As for preferring library over frameworks, sure why not. There are tons of reason to be able to do things other than the way that is described by a framework, but when you start to have teams bigger than 20, of different time zones, with varying skill level (important point here), having a prescribed way to do things may not be such a bad thing. There will be time to break the rules of the framework, but hopefully your choice of framework is good enough that it should only be less than 10% of the case.
To this, I can say that despite the failing of AngularJS, some teams just cannot live without it. Its very prescriptive to the point that people who a very good at Javascript may find it repulsive. But those prescription are just too robust for some team to abandon it and go for a more performant framework.
And there is a lot of companies that can't hire Google level developers. These people may not know Javascript enough, but are okay as long as there are good prescriptive example of how to do things. They should still aspire to be good at Javascript (or any language at that...), but sometimes that seems to be too much to expect for the portion of them. Sure, this is not ideal, but you have to remember, there are a lot of places in the world that IT is a cost center.
[+] [-] Bahamut|11 years ago|reply
[+] [-] colin_jack|11 years ago|reply
[+] [-] dasil003|11 years ago|reply
The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago. The amount of experience and expertise that is being codified in (for example) Ember.js is fantastic and will allow you write much richer web apps in far less code than trying to achieve the same functionality with it.
Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.
[+] [-] joesmo|11 years ago|reply
That pretty much sums up the article's stance on frameworks. Even with reusable components, there will be a need for frameworks because just using JS/CSS/HTML directly, one would essentially be creating a framework with each application. There are standard things that a framework encapsulates in any language or target environment which will be unnecessarily repeated and sub-optimally created if one decided to start from scratch on every application. I think the author misses this part completely. While learning a framework enough to start making things in it may take a day or two, creating a new framework because one hate using frameworks will take days to weeks and still likely leave desiring functionality they had not thought of or had implemented badly.
[+] [-] abnormalbrains|11 years ago|reply
I'd dispute that. 10 years ago we had pretty brilliant browser based apps. They just happened to be using flash or Java applets whereas now they're using javascript.
[+] [-] forrestthewoods|11 years ago|reply
[+] [-] shripadk|11 years ago|reply
Jokes aside, React provides a Virtual DOM which isn't available natively. I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore. Until then, React is the best way forward. There are plenty of thin VDOM libraries (some even more efficient than React) out there but the joy of working with code written as composable Components outweighs efficiency (I'm sure those libraries would fare far worse in benchmarks if composability is put into the equation). Couple this with a library like Om/Reagent and you get FP (code as data)+immutability handed to you on a silver platter.
Without the "right" libraries you introduce a lot of incidental complexity into your application development lifecycle.
[+] [-] masklinn|11 years ago|reply
React is a framework though, for the most part it calls you(r components), you don't call it outside of the original binding. It's not a huge one, but it's still one.
> I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore.
Browsers already batch changes and defer recomputations as much as they can. They can't significantly improve the model because it requires a different abstraction which is not available under the existing DOM.
Also, you can use a VDOM without using React and its component, several VDOM-only pure=js libraries have sprouted up e.g. https://github.com/Matt-Esch/virtual-dom (the basis for elm-html, and the Mercury react-like framework)
[+] [-] Bahamut|11 years ago|reply
[+] [-] Touche|11 years ago|reply
[+] [-] bstrom|11 years ago|reply
[+] [-] gsands|11 years ago|reply
[+] [-] davedx|11 years ago|reply
[+] [-] frik|11 years ago|reply
But all these old monolithic frameworks/libraries, that try to solve everything and there citchen sink, are so 2009-ish.
They have its place in the enterprise world. And for performance optimisation you want a more modular approach.
[+] [-] jfaucett|11 years ago|reply
Personally I'm with you, I enjoy a small, isolated, component based approach where each component follows the unix philosophy. I think this lets you write the most performant and resuable code. Also, I think when following this style, it limits the scope of your dependences, which is another big plus. For instance, you might need a library for crypto, but you won't need one for doing your authentication system, and you won't have massive modules for handling auth that would come from a framework getting compiled into your production code.
But when you go this route you do have to make a lot of "right" decisions that are made for you when using a framework. Also, I think a lot has to do with deadlines and developer speed, it initially takes a little longer to write good standalone components that are reusable, and just grabbing some framework will help get shit done in the short term, but might have the same detriments as technical debt in the long run.
[+] [-] colin_jack|11 years ago|reply
Something like React bothers me far less as it smaller, less imposing, and solves real problems I've seen with other frameworks (for example by pushing clear/consistent/simple communication paths).
[+] [-] lukeasrodgers|11 years ago|reply
[+] [-] gildas|11 years ago|reply
Except React is a library. The slogan [1] clearly says "A JavaScript library for building user interfaces".
[1] http://facebook.github.io/react/
[+] [-] Osiris|11 years ago|reply
Frameworks are created because they make solving certain types of problems easier and reduce code duplication, whether you use someone else's or your own.
[+] [-] kyllo|11 years ago|reply
A framework has control of the application by default and gives control to your code at designated points, to perform some computation and then return control to the framework.
A library takes control of the application when/where your code calls it, performs some computation and then returns control to your code.
A library is a way to reuse code; a framework is a way to reuse application structure/design and control flow.
The pain points of frameworks are well known at this point, I guess the question is given a really good set of high-level libraries, could you be as productive as you are using a framework? Maybe not at first, because you have more design choices to make. But later, you have less of other people's design choices restricting you.
[+] [-] davvolun|11 years ago|reply
Besides that there are 4 things listed there, not to mention how each interacts with the other, this is not a problem. If you shy at learning an additional thing, you should get out now.
That's not to say you shouldn't strive to reduce complexity and dependencies, that's a laudable and useful goal. But it's my personal opinion that every programmer out there should know at least a handful of languages, concepts, paradigms or frameworks that they don't like or have no use for--it's the same basis of learning more from failure than success.
That being said, I sincerely disagree with the assertion of the article, if on nothing more than the abstraction argument. The abstractions of jQuery have saved me so much time over the years with systems that work great in the latest and greatest browser, and work well enough, possibly with minor tweaks, in older browsers. Rewriting browser detection junk and making sure each control mostly works independent of browser and engine would be a much larger waste of my time than learning three or four js frameworks.
[+] [-] al2o3cr|11 years ago|reply
As opposed to the non-framework case, where you have HTML+CSS+JS, N libraries, and all your custom glue code... Yup, that's WAY easier.
[+] [-] colin_jack|11 years ago|reply
Don't forget he was part of the REST/ROA group who were belittled when they said that Web standards were an alternative to the ridiculous number of Web Service standards and he was quite right in that case.
[+] [-] pothibo|11 years ago|reply
Solutions exist outside the scope of JS framework. We only need to take a minute to analyze them. It's not a popular decision to avoid JS frameworks but I believe some criticism of the current solutions available is in order.
[+] [-] fiatjaf|11 years ago|reply
[+] [-] k__|11 years ago|reply
Which is (mostly) monolithic, but rather small. Feels like a simple wrapper.
[+] [-] emsy|11 years ago|reply
a) Todays technology is deprecated tomorrow
b) When someone joins I'm the one who'll have to teach them
[+] [-] Bargs|11 years ago|reply
Starting a project today, I can build a client in Javascript, hook it up to an API, and I'm done. NPM and Browserify make dependency management and builds a breeze. There's very little friction in the development workflow because the front-end build process it totally separate from the server. I make a change, save it, reload the page and I see my changes live without even running a server locally. Even PHP's deployment story isn't that simple.
It's true that the initial setup is more complicated than simply downloading jQuery and plopping it into an existing project, but if you have the option of separating your client and server code, it really simplifies things overall.
[+] [-] debaserab2|11 years ago|reply
Frameworks give us a language to speak to each other about the nuts and bolts of our application. This means new developers can get ramped up quickly (provided they understand the framework) and there is a common body of best practices that can be referenced when faced with difficult problems. There's a lot of value in that.
[+] [-] progx|11 years ago|reply
Most problems are simple, but to solve them in a framework, you have much todo.
And when you understand and use everything "the right way", the new Version of the Framework arrive -> see angualar v2. A new Framework with a new underlying language (WTF?)
Best practices work without frameworks too, you have only to define them and communicate them with your co-coders.
Since requirejs with the modularity and different build tools, i feel no need for a huge framework.
I pick the libraries i need and build parts of the application into modules, since the communication run with events it is clean, structured and has a clear defined API.
[+] [-] colin_jack|11 years ago|reply
Agreed that is an advantage of frameworks, but is it not more of an argument for a mature framework like Rails, rather than the current JS frameworks which appear and become (essentially)obsolete/niche in a year or two?
[+] [-] markuz|11 years ago|reply
[+] [-] duaneb|11 years ago|reply
These are the core benefits of frameworks:
1. Standard code style.
2. There's only one way to do it (ideally).
3. Modularization.
4. Unit testing.
5. A realistic standard library for async/concurrent computation.
Angular, for instance, provides dependency injection and $scope/$digest. It would be pretty ridiculous to attempt to replicate those benefits until AT THE VERY LEAST Object.observe has solidified in terms of support. And even then, you're on your own in terms of mocking, in terms of communication between different modules, in terms of libraries you can drop in without dragging in a framework itself.
I'm appreciative of the attitude, but it's quite simply not a reality for people who don't want to invest in establishing their own patterns—in effect, writing a framework. With a framework, people can sit down and use the engineering techniques they've learned from other areas of CS and write an application without being bogged down in terms of figuring out how to write a high-performance single-threaded web app in a language without modules, integers, futures (or other similar async abstractions), calendar widgets.
Try going without JQuery for a day and see how much duplicate code you write.
Then, multiply yourself times a team of 10.... good luck.
[+] [-] jacquesm|11 years ago|reply
[+] [-] tkubacki|11 years ago|reply
[+] [-] john1108|11 years ago|reply
[1] https://github.com/Financial-Times/polyfill-service
[+] [-] Bockit|11 years ago|reply
[+] [-] encoderer|11 years ago|reply
[+] [-] rapind|11 years ago|reply
Here's an interesting and fairly detailed article about a different approach: http://jlongster.com/Removing-User-Interface-Complexity,-or-...
Best of both worlds? https://github.com/PixelsCommander/ReactiveElements
[+] [-] drogus|11 years ago|reply
My summary of that text: "I don't know how frameworks work, so let's not use them".
[+] [-] maxerickson|11 years ago|reply
http://bitworking.org/news/Why_so_many_Python_web_frameworks
(That's a post assembling a light framework from libraries...)
They just didn't go through the list of features and explain that each one doesn't necessarily need to be coupled to the others.
[+] [-] lordbusiness|11 years ago|reply
"Reinvent everything from scratch, all the time."
[+] [-] bipin-nag|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] arenaninja|11 years ago|reply
[+] [-] fiatjaf|11 years ago|reply