We added a sidebar with learning resources to the demo pages in the last release of http://todomvc.com which we constantly update. Obviously, that's only an entry point for further research, but I think for most libraries or frameworks it's easier to maintain those kinds of information in one place.
Thanks. That list is missing all four frameworks/toolkits/libraries that I'm using: Ember, Knockout, Backbone, and React. Also Grunt+RequireJS vs. Gulp+Browserify due to the HN post earlier. That said, I'll donate $50 to Wikipedia & $50 to TodoMVC because they're both very helpful.
If you constantly find yourself looking at new frameworks to save time, reduce boilerplate, make development and debugging easier, you may want to acknowledge that it's not the framework at fault, but the language itself...
The reflection may not stop at the language. Many of these "terrible" framework/languages have plenty of folks accomplishing a lot of stuff with them.
Not trying to claim that everyone that complains is bad/wrong. Rather, the field often acknowledges that learning a new language can help "learn a new way to think." Seems that sometimes we neglect that one needs to learn the way of thinking for the language/framework they have, and less worrying about the language/framework they wish they had.
The amount of 'bad/wrong' frameworks that are present in PHP (as an example, don't mean to hate-monger) is astounding. These are usually the 'discontinued' ones that people have gotten used to and find a hard time moving on from, so in some cases I think it is reasonable to look for a new framework rather than continuously hacking their way to the finishing line.
That may be, but when the rubber hits the floor, you are often better learning to "think in the framework" that you have, than you are trying to reinvent yet again. This can be just as true when considering new frameworks. They may be better, but that doesn't mean you have time for them.
And I fully acknowledge that this is an art. Knowing when to consider making a change is a tough piece of knowledge to try and hammer down.
I think that the problem is not the language. The elephant in the room is DOM. Javascript is just the poor (in the sense, that it has the fate to deal with it) tool we have to manipulate that. All those frameworks and new APIs are just an attempt to put more lipstick on a pig.
After spending some time in the JS and NodeJS world, I feel there are waaay too many immature libraries out there.
It's very easy to publish a library in the JS world. Just add some boilerplate and everyone can grab it through npm or bower. In the Java world getting it in a repo through maven is a bit harder. But that leads to fewer projects to maintain and focus on, in the JS world it's a bit too "forked" for my taste.
I don't think this article is giving enough consideration to what's going on with web application development.
JavaScript is the de facto language of the web, so everyone is using it whether it's the right tool for the job or not. The web is also rapidly evolving its capabilities, so web applications are constantly changing in nature.
YAFS is not really the problem, it's a symptom of a massively developed for, single language, massively used platform. I'm sure it's exacerbated a bit by javascript being such a poorly designed language, but this is more minor.
The solution isn't "research and mold what's already out there to your problem", because this is only addressing the symptom. There's an explosion of frameworks because there's an explosion of different use cases and application goals on the web.
Rather than having to choose between 20 different programming languages, you have to choose between 20 frameworks.
Perhaps because a to do list is so simple it can be covered by every type of framework, and doesn't warrant using the very features that justify each framework. I agree there's lots of "reinventing the wheel", but I don't think there's as much noise to value as they think.
I'm skeptical about all these new frameworks solving uniquely new things. This is not a syndrome of the Javascript community alone but of all IT: we never look to previous solutions and research, and think we are discovering the wheel every day.
Be it IT vendors rediscovering "cloud" concepts that were published in the 70's or a JS developer releasing a new framework that he rewrote using more functional idioms because object orientation is so-yesterday.
Besides it getting boring for us old farts, it feels exactly how the author describes it: more noise than value.
Not only published, I did use cloud computing in the 70's - we called it time sharing. And our keyval, schemaless databases obviously couldn't be called noSQL before the advent of SQL!
Cloud computing and time sharing are not the same thing, though. Time sharing was just a way for multiple people to access the same computer at the same time. In cloud computing, people aren't accessing a particular computer as far as they're concerned; they're accessing a service that's out there somewhere, and they might even have two consecutive requests handled by computers in different data centers.
If you want to distill all of what "the cloud" means into just "accessing a service", then sure. Nothing's changed in 40 years because it's all still just "clients" accessing "services".
Also, transportation hasn't changed in millenia because we're still just humans moving places, and information retrieval hasn't changed since the invention of the written word, because we're still just absorbing information from glyphs on something that has distinct colors.
Well, he said that "accessing a service that's out there somewhere" is "exactly" what IBM was offering in the 70's. I interpret that to mean that it hasn't changed.
You are right. The technology has evolved but the concept is the same; we had terminal servers connected to the nearest point of their private network over a dedicated line and they run our software in one or more of their servers.
IMHO the problem is more about front-end javascript than nodejs since Javascript doesnt have a module system,there is no rule as to how to write a library and include it in one's code. CommonJS and AMD are not JS specs. Ajax and the DOM are not javascript.
So front-end devs , instead of writing libraries that depend on other solid(and maintained) projects, either include dependencies or rewrite stuffs they will not maintain. That's the nature of javascript.
As for the question is there too many frameworks, I disagree. devs will mostly use frameworks that are well documented and maintained. If the last commit in your project was 2 years ago, if you dont have an issue tracker set up or you dont fix bugs, if there is no test other devs aint gona use your library that's a fact.
But again , open source projects are basically free work,so let's not complain. Let's also not forget that Javascript is usually easy to read and to fix. We are not talking about fixing some C++ here...
As a dev it is also your responsability to vet libraries.
I would say there is a proliferation of immature libraries and a dearth of mature JavaScript frameworks and libraries that meet the needs and desires of today's app developers. Mature frameworks are typically the work of many developers over several years, and they require time, money, and good product management, among other things. Five years ago it seemed a little off the wall to start a company whose customers were JavaScript programmers (I did it), but that's no longer the case, so I expect times will change.
I hope people invent lots of new ways to do things, and I hope the go-to software of five years from now is not the go-to software of today. I hope we aren't using jQuery and Mongo in ten years.
Code can be a very intimate affair. When taking on a new requirement that can be fulfilled by an existing framework, there's a lot more to consider than just "did someone already implement this"?
In the corporate world, we often remind younger developers that most of the cost of the code is in the maintenance, not in the development, of software. Having to tackle feature changes dependent on 3rd party software can be really expensive.
If I'm working on a hobby project, I don't have enough time to do a full evaluation of all options out there, nor do I have time to understand the intricacies of a given framework to meet my unique requirements.
So, often, it takes just as much time to come up with my own mini-framework and build it up as my requirements increase. If I reach a certain level of functionality, then I may have something that I can share with other developers. Everyone always touts the benefits of open source, and I may want to get in on that, too. Besides, there's more glory in starting a project than being the 51st person to contribute.
Disclaimer: I don't have my own framework, and has in the past been the Nth contributor to what was then a de facto standard framework.
I've dealt with number three so many times. It just seems like a trivial fix to make the npm search more useful. It needs some kind of rating system combined with sorting by recently updated, and popularity.
A framework without documentation, is not a framework at all. The article spends a bit of time on this, but I believe it's worth reiterating. The reason for using a framework is to not have to rewrite common functionality. Without good, complete documentation (both in code and external to the framework) one cannot even evaluate a framework in a timely manner.
While doc-blocks and comments are crucial to all code, and especially crucial to framework code, a framework that relies solely on auto-generated documentation is one without complete documentation. There is more to documentation and the coherency of a framework and its use cases than describing its microscopic parts.
After years of dealing with the same issue in PHP, I have come to the conclusion that frameworks should be evaluated based on two criteria:
1) How quickly can a developer who is competent in the language (ie. a non ninja-rock-star) but has never heard of the framework understand what's going on?
2) How hard is it to take the value that I create (ie. the code I write) and move it to a different solution?
Of course the result of these is that the best framework is no framework at all... In the case of PHP, at least.... in JS it may be the case that some minimal framework is required, but as much as possible I think that libraries, more than frameworks, are the key to this issue.
Actually I think in PHP's case the best framework is at best minimal, but something more than none at all. Anything beyond Composer and a PSR autoloader to manage libraries, a router to abstract requests from the filesystem and (arguably) a templating engine is nice but not absolutely necessary. But I think PHP is a nightmare without at least that.
And yet, if I were to meet someone who was a few months into a new js web app, I could probably guess which framework they were using with 5 guesses or less 95% of the time. Also, I would bet that all 5 of the top frameworks will be reasonably supported for the next 5 years. As for the many frameworks that make up the last 5% of usage and have shakier futures, I doubt many new devs are actually using them.
It is always a red flag for me when someone starts arguing for less choice, more monolithic frameworks, and the inevitable lock in that comes along with having only one or two options.
The biggest issue is the glorification of web-development. It's just a GUI layer in a weak script language in the end of day. Just pick any framework you like at the moment, there will ten new ones by the time your next project starts.
43 comments
[ 3.7 ms ] story [ 109 ms ] threadhttp://www.jsdb.io
http://jster.net
Not trying to claim that everyone that complains is bad/wrong. Rather, the field often acknowledges that learning a new language can help "learn a new way to think." Seems that sometimes we neglect that one needs to learn the way of thinking for the language/framework they have, and less worrying about the language/framework they wish they had.
And I fully acknowledge that this is an art. Knowing when to consider making a change is a tough piece of knowledge to try and hammer down.
It's very easy to publish a library in the JS world. Just add some boilerplate and everyone can grab it through npm or bower. In the Java world getting it in a repo through maven is a bit harder. But that leads to fewer projects to maintain and focus on, in the JS world it's a bit too "forked" for my taste.
JavaScript is the de facto language of the web, so everyone is using it whether it's the right tool for the job or not. The web is also rapidly evolving its capabilities, so web applications are constantly changing in nature.
YAFS is not really the problem, it's a symptom of a massively developed for, single language, massively used platform. I'm sure it's exacerbated a bit by javascript being such a poorly designed language, but this is more minor.
The solution isn't "research and mold what's already out there to your problem", because this is only addressing the symptom. There's an explosion of frameworks because there's an explosion of different use cases and application goals on the web.
Rather than having to choose between 20 different programming languages, you have to choose between 20 frameworks.
And they receive pull requests for several MVC frameworks each week demonstrating how to build a to do list in a new framework.
I don't think that you're talking about the same thing here.
Be it IT vendors rediscovering "cloud" concepts that were published in the 70's or a JS developer releasing a new framework that he rewrote using more functional idioms because object orientation is so-yesterday.
Besides it getting boring for us old farts, it feels exactly how the author describes it: more noise than value.
Not only published, I did use cloud computing in the 70's - we called it time sharing. And our keyval, schemaless databases obviously couldn't be called noSQL before the advent of SQL!
Exactly what IBM offered in the late 70's.
Also, transportation hasn't changed in millenia because we're still just humans moving places, and information retrieval hasn't changed since the invention of the written word, because we're still just absorbing information from glyphs on something that has distinct colors.
That's something I see as the sign of a poor / inexperienced developer. Assuming they can do something better than an accepted well tested solution.
Also why I can't sop far get too excited about NoSQL, its the same as Berkley DB was years ago more or less, no?
So front-end devs , instead of writing libraries that depend on other solid(and maintained) projects, either include dependencies or rewrite stuffs they will not maintain. That's the nature of javascript.
As for the question is there too many frameworks, I disagree. devs will mostly use frameworks that are well documented and maintained. If the last commit in your project was 2 years ago, if you dont have an issue tracker set up or you dont fix bugs, if there is no test other devs aint gona use your library that's a fact.
But again , open source projects are basically free work,so let's not complain. Let's also not forget that Javascript is usually easy to read and to fix. We are not talking about fixing some C++ here...
As a dev it is also your responsability to vet libraries.
I hope people invent lots of new ways to do things, and I hope the go-to software of five years from now is not the go-to software of today. I hope we aren't using jQuery and Mongo in ten years.
Code can be a very intimate affair. When taking on a new requirement that can be fulfilled by an existing framework, there's a lot more to consider than just "did someone already implement this"?
In the corporate world, we often remind younger developers that most of the cost of the code is in the maintenance, not in the development, of software. Having to tackle feature changes dependent on 3rd party software can be really expensive.
If I'm working on a hobby project, I don't have enough time to do a full evaluation of all options out there, nor do I have time to understand the intricacies of a given framework to meet my unique requirements.
So, often, it takes just as much time to come up with my own mini-framework and build it up as my requirements increase. If I reach a certain level of functionality, then I may have something that I can share with other developers. Everyone always touts the benefits of open source, and I may want to get in on that, too. Besides, there's more glory in starting a project than being the 51st person to contribute.
Disclaimer: I don't have my own framework, and has in the past been the Nth contributor to what was then a de facto standard framework.
While doc-blocks and comments are crucial to all code, and especially crucial to framework code, a framework that relies solely on auto-generated documentation is one without complete documentation. There is more to documentation and the coherency of a framework and its use cases than describing its microscopic parts.
1) How quickly can a developer who is competent in the language (ie. a non ninja-rock-star) but has never heard of the framework understand what's going on?
2) How hard is it to take the value that I create (ie. the code I write) and move it to a different solution?
Of course the result of these is that the best framework is no framework at all... In the case of PHP, at least.... in JS it may be the case that some minimal framework is required, but as much as possible I think that libraries, more than frameworks, are the key to this issue.
It is always a red flag for me when someone starts arguing for less choice, more monolithic frameworks, and the inevitable lock in that comes along with having only one or two options.
Perhaps the problem is that we have a large opportunity before us and it isn't obvious which frameworks are going to win.