The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them.
Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the other end of the spectrum, the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time.
I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration).
Of course, I have no numbers to back any of this up - it's just an observation (one skewed by personal experience, no doubt).
You can spin it this way if you like. However, a big part of this framework and Tool epidemic is ego. The trick is to take a dominant framework or tool, find a deficiency, and then rewrite it again with that deficiency fixed. Why? Because if it takes off, your career takes of.
What developers should really do is contribute and make the existing projects better. Everyone will thank you for it.
It actually helps if you contribute to an existing project, because it is like, you worked with others on an existing codebase and contributed features in a big project which has high visiblity and is being used in real life by real people.
Much of what we work is all with people and on large codebase, so if you are contributing to existing project, it is actually helpful for interviews. Also it takes weeks to get a PR accepted, so if you actually were successful in getting your feature accepted, it shows your resolve to contribute the feature because you want to contribute and not because you want to do a PR stunt for your career (and not get annoyed by the constant changes which the authors ask, which are close to a million)
You took the words right out of my mouth. It has more to do with ego than everything else, and you can tell because most competing tools, in JS anyway, don't have a significant edge over the others and are largely the same tool reimplemented without much of a concrete goal besides "performance" and "scalability ". Like you said, taking an existing tool with a deficiency and rewriting it from scratch without that deficiency. Advances have occurred for sure, but not without some massive failures from not having a good roadmap. Brute force, in other words. The projects that do have more concrete goals and vastly different methodologies in the JS world happen to be low in popularity, relatively speaking. I wonder if the inflated egos in the JS community comes from all the talk of "Node.JS is the future" in recent years. There aren't nearly as many competing projects in the Ruby world, or Python or even PHP.
I second the part about ego. I once wanted to write a BaaS because I was not happy with parse-server. After considering the time efforts and comparing it with the efforts to improve parse-server I decided to just improve that software and don't care about my own project, because I try to value my time higher than my ego. It isn't easy to be rational if your ego is involved.
But it's also difficult to decide if it's worth it, especially if you've found a real deficiency. The creator of http://propelorm.org said to me that his framework gets him €120k+ offers and that he recommends building open source projects that are in demand.
So I don't think it's possible to give a definite answer what developers should really do. Maybe bit of both?
However, there is also something to be said for rewriting work. There's the concept of "plan to throw it away"[0] I think a lot of these projects start because people are just trying to learn. Then they share them and get built upon. You then have an ever increasing amount of technical debt, eventually inspiring others to write a simpler version and then that becomes the defacto and so it continues...
I think my favorite example of just stupid stuff that keeps getting propagated is the Date type in javascript - the month field starts with "0", but the day field starts at "1"[1]. Like what is with that?
Even with everyone contributing to Javascript that stupid thing still exists because you can't break the internet to fix it (ask the Python community how changing a lot of syntax works out - although Python wasn't even that bad). That's why people write new stuff, because they want to make things simpler. Not really something to complain about IMO.
The unique stuff I learned is probably just these four languages: BASIC, C, C++, Python - I learned it in that order and now I can pretty much do w.e. language I need to use. Because all frameworks are based off the same stuff. Go is easy, Javascript - no problem!, I do full-stack work and data science in my day job it's really not hard at all. All the frameworks make it even easier.
Many more JavaScript tools and libraries have websites that are visually appealing than for any other tool or technology that I've seen. Since the informational content is usually not of a similar or higher quality in my experience, it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)
I'm also entertaining the thought that JS development might be a more solitary work (on average), which could conceivably also influence if you choose to cooperate rather than build anew yourself. Most JS tools were also not very big, as they had to be delivered to the client, and as such more amenable to being built by a lone developer or a small team.
The only thing I known for sure is that in 20 years of coding, nothing have confused me as much as the plethora of JS 'things', not even DCOM or the almost unequivocal praise of Hibernate (for a while)
>Many more JavaScript tools and libraries have websites that are visually appealing than for any other tool or technology that I've seen. Since the informational content is usually not of a similar or higher quality in my experience, it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)
I agree with your other points, but this one is easily explained by the fact that people who specialize in Javascript tend to be in the front-end/UI development field, and thus are more likely to have an artistic background/sensibilities.
Both could be true. In my experience outside perception is quite a bit more important to people with artistic background than to the average programmer.
> (...) it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)
I think you read too much into it. The front-end of a website would be important for tools which help making front-ends of websites, don't you think?
> I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration).
I think this description matches the Python web ecosystem quite well. Historically there were the Z(ope)-ish projects, which still exist and are being used (and they work quite nice); Django obviously dominated for a long time, but in more recent years some healthy competition ensued (Flask and it's highly modular approach for example, but also Pyramid), which resulted in a lot of reworking and improvement for all frameworks. Django now vs. Django 2010 is a vast difference in developer and user friendliness. Some specialized frameworks popped up (Tornado comes to mind), but overall there isn't a heavy fragmentation of the ecosystem (bad) but no one dominator either (bad).
I'm curious, has anyone performed a comparative study that breaks this down e.g. correlating aspects of language design to systemic structures in the resulting ecosystem?
I have often wondered whether the level of complaint relating to Javascript framework proliferation is explainable as due to language structures (whether notably present or notably absent) or unusual initial conditions of the JS community/ecosystem.
Is there even a field of techno-psycho-sociological studies, and is there an equivalent of the Sapir-Whorf hypothesis for programming language ecosystems?
> the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time
This isn't a problem by itself, the problem is the ever-changing "clear winners" and hordes of people using them with no understanding of their trade-offs.
I hear complaints like this a lot: "It was so easy to-do this with jQuery, why is this JS-framework-de-jour so complicated?" - well, why didn't you start with what-you-know and explore their limits litte bit, so you would know what you really needed?
With Ruby and Rails, you have a single answer to many use-cases, with JS and the npm, you have many answers to each use-case imaginable and choosing by popularity is very damaging.
Language communities are in an arms race to create the best platform for the Cambrian Explosion of tools necessary to support a dramatically growing and diversifying developer population. Languages with a proliferation of tools, where developers are experiencing choice fatigue, have the incentive and the usage data necessary to design the meta-tools that will make development in such an environment easy. Languages which rely on small selection to solve the problem will remain niche languages.
We're just waiting for some innovations in package/community/docuentation/source control management to crystalize and make the whole problem moot.
Right now it seems very clear that React, Redux, and Webpack are winners.
The difference, I think, is that many of these tools are simple enough that if you have a new idea you will simply write a replacement instead of trying to work with the maintainers to push out a dramatically different new release.
I agree that there is a high risk of project abandonment and it is frustrating that we haven't yet found a consensus around javascript frameworks. But, I would argue that Rails became dominant because it was so much better than the alternatives, we're in the messy part of the cycle where we're not sure what the next great/common/standard library or framework is going to be, but on a long enough timeline I'm confident that the best abstractions/communities/frameworks/libraries will be the most popular, because they allow developers to produce the best things quickly. We're a part of the immune system that helps us to converge to that reality.
I think it's a JS problem with trends around other languages tending moreso to a single eco-system.
Regarding JS frameworks, I think the barrier to entry is still low, and given the suffering involved for any given tool-chain, I'd imagine the temptation to roll ones own is high.
Finally, JS framework fates are tethered to that of the browser. The latter changes frequently, so the former ends up in a refactoring perma-loop.
> Finally, JS framework fates are tethered to that of the browser. The latter changes frequently, so the former ends up in a refactoring perma-loop.
Could you elaborate on that? What kind of browser changes are happening so often and are so deep that frameworks need to be refactored every time? (My experience is quite the opposite.)
For side projects, it can be a little daunting, but ultimately represents a healthy eco-system.
But the issue for me is how employers handles it. No, I don't know Angular. But I have used Backbone, Ember & React. So do you really need an Angular expert, especially when Angular is only a few years old and is completely changing in Angular 2?
Should employers insist on extensive trade knowledge in a specific framework, or should they be able to hire based on understanding of development and architectural principles, and give a new employee a little bit of leeway to get up to speed on their stack.
If it's the latter, then you can relax, and focus on reinforcing good practices and understanding the theory about what you're working on, and your resume will continue to build.
If it's the former, then you have to constantly pad your resume with skunkworks projects simply so it doesn't seem like you're getting "left behind." And that is exhausting, and not very useful to anyone.
I think the real markers should be that a person is not afraid of broadening their views. Usually, the advice for hiring for Erlang, as an example, is not to hire people that know Erlang, but focus on hiring good people (who are capable of learning beyond your average C-like) and then teach them Erlang. It's a small and very easily learned language, for sure, but learning it is certainly a bigger undertaking than learning a JS framework.
It astounds me that hiring for JS frameworks actually is that specific, considering you're likely passing up on people that are simply better problem solvers.
I've been trying to learn Angular2 recently, maybe I'm not a good developer (but I faired ok with Erlang :D), but it really is such a struggle. Documentation is lacking, and what is available is often wrong or outdated. It doesn't help that half the tools and libraries are still in 'beta' and breaking changes are seen as a way of life.
This post really sums up my experience, and I've done plenty of Javascript before (I just haven't kept on top of client side frameworks):
If I were to hire someone to work with me, I would try and find someone who has experience with Angular2. Angular2 vs JavaScript are effectively different technologies compared to Ruby vs Rails.
I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2.
Angular2 is a special case, in that a lot of the frustrations you're feeling are probably not far off from the frustrations that Angular1 developers are feeling.
The decisions they made going from Angular1 to Angular2 are a big reason I've never really bothered with Angular.
Just on a base level, if a system isn't properly documented, that does make a case for finding someone with indepth knowledge.
But a company using a system that is very poorly documented as their core technology is a big red flag for me.
Some tools are "simple and powerful", other tools are "complex and powerless"¹.
The first set is normally seen as "hard", because it is very easy to shoot oneself at the foot with them, and because experts tend to be attracted by them. The second set is often seen as "easy" because the complex features are normally there to stop novices from harming themselves.
The unexpected thing is that "simple" is much easier to learn than "complex", independently of what other adjectives come bundled with them.
1 - Yes, the other 2 combinations exist. "Simple and powerless" does not make the headlines, and "complex and powerful" is very, very rare.
Angular (prolly the same of Angular2) is that it's magical hiding the underlying browser mechanic, DOM manipulation. It's is hidden below layers of fancy syntax. Whereas with reactjs you have a kind of steap learning curve in the sens that you have to grok an ecosystem of diverse communities (ex: gulp, flux, webpack) but for Javascripters that's almost part of the regular shore when you are used to build you own framework. AND ReactJS reuse most concepts from vanilla Javascript and DOM.
Well yes, Erlang is pretty well-thought out, has a decent standard library, decades of serious production use, and couple of community-blessed books you can learn from.
> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2.
I suppose that might be the case. It feels incredibly counter-intuitive, but it's not inconceivable that the JS frameworks stray that far from "normal JS".
Were I in this situation as a employer (and co-worker, necessarily, not only in a managerial position), I would probably make the decision to use other technologies and compile to JS, in that case. There's very little to gain from using a framework that by necessity is tied to a crummy language if I can skip using that as a source language anyway, and then I'd just go with something sane like Elm instead.
(Bear in mind, this is coming from someone who doesn't actually work with front-end development, so take it with a grain of salt.)
The AdWords team could have chosen any of a fairly large number of technologies to develop their new front end, but they chose the Dart version of Angular 2 to do so.
CircleCI chose to use ClojureScript and Om instead of using React directly. NoRedInk chose to use Elm instead of writing JavaScript directly. Others have chosen ScalaJS.
It's not popular in the startup world, but plenty of companies chose (and continue to choose) to use GWT to build their in-browser user interfaces. I worked at one of them back in 2010. I had huge doubts about the Java-to-JS compilation process. I'd mostly only seen ugly GWT apps cobboled together from the UGLY base components GWT shipped with. As it turned out, we were able to created our own good looking components quite easily. So long before Angular or React existed, we were able to create a nice an easy to understand component based web app, with business logic split out into services and wired together with dependency injection. It ended up being a sane choice that enabled us to continue developing safely and sanely as the app became larger, and it performed very well on both desktop and mobile browsers. GWT wouldn't be my first choice (or second, or third) in 2016, but it ended up being a pretty good one in 2010.
I'm not saying that choosing a compile-to-JS language that has very different semantics than JS is necessarily sane and practical. But I think that plenty of real world successes demonstrate that this choice can be simultaneously sane, practical, and successful.
Impractical how? I'm curious. Writing JS strikes me as impractical from the get-go. Writing in a managed language that will compile down to JS and give you an escape hatch for when you really need it strikes me as far more practical in the long run.
To clarify, what I mean is that someone who can't learn Elm, PureScript, Bucklescript or the like, very likely isn't a very inquisitive person and isn't someone I'd like to work with. On top of that, someone who can't see why you'd want to write in any of those languages instead of JS very likely isn't someone who I would want to work with, for fairly obvious reasons.
(This isn't a personal attack on you or your ability, I don't know you)
I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible.
Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing.
If you take an ember / backbone / whatever expert and give them a few weeks angular training they'll rock a todomvc but full apps often end up with controller-as-a-god-object.
Genuine experts would be really nice to find, but it's really difficult because frameworks aren't given time to mature before the smartest people have moved on to other frameworks.
You're right that employers should hire on general understanding and give time, but the required time is typically 6 months and a failed project or two. Many employers don't make and don't want to make that kind of human-capital investment anymore.
The "rockstar" who knocked something up pads their resume with another project with a hot new framework, got experience with another new set of tooling and can leverage that to move somewhere else to produce more working but hard to maintain code in another hot new framework because their CV is padded with experience showing they're a quick learner, but the company left behind pays the cost in maintenance.
A genuine angular expert will likely be well employed for a while come helping troubleshoot and clean up the mess left by the cool crowd.
p.s. I am not an angular dev, this complaint can be leveled at a lot of hot new tech, particularly but not just the javascript front-end world, it equally applies to people who knocked up go microservices at a .Net shop, or hastily introduced mongo to replace oracle, etc., etc.
> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible.
Outside of a hire-an-expert consulting gig, I really would say the problem here lies almost exclusively on the engineering management, or lack thereof, and broader staffing decisions. I don't think it's necessary to have a project fail for someone to understand a tool[1] but the ability for someone to get up to speed is a function of the time invested in things like mentoring and code-review.
Yes, many companies make the short-sighted decision to skimp on that investment but that needs to be recognized and fought as a management problem – any project is going to suffer in those conditions even if your entire team is staffed with experts because understanding the actual business problems is as hard as the tech stack and if you can't carve out time to think about a few controllers, there's no way that the rest of the problem doesn't have problems which are at least as bad.
1. If true, that would be a huge sign that the tool has major design failures and is not suitable for production use rather than an argument against hiring people who aren't already experts.
> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible.
>
> Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing.
A possible approach is to let developers new to a framework on a prototype or toy project first, and, very important, throw away that prototype.
Yes, that means you might have to wait two or three weeks longer until you get started with the real project, but the result will be so much better.
But that's one of the prices you pay for using an immature technology. For a more mature one, you could read a book on successful usage pattern of the technology.
Not at all. Angular, from an architectural standpoint, is not something I would necessarily gravitate towards, although given a little time and proper documentation, I'm confident I could build something in it, so I don't feel very left out.
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?
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/ 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.
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).
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?
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.
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."
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.
I think the complaint about too many tools is really just a euphemism for complaining about peer and employer pressure to always be up-to-date with the latest tools and styles. Developers live in constant fear of falling behind.
But is this pressure justified? I see two possibilities:
a) The latest crop of the top 10% tools really makes us much more productive than last year's crop of the top 10% tools. So the best developers will always filter through a lot of new tools to find the best 10% and benefit from them.
b) After accounting for productivity losses incurred by constantly relearning and rewriting everything, the lastest best tools have no productivity benefits. They are just a distraction from the product we're supposed to be working on.
I don't think there is ever a time in history when this question can be answered unequivocally, and therefore it is never possible for good developers to stop looking for better tools completely.
However, I feel that at no time in the past quarter century has the pendulum swung so far in the direction of (b) where front end development is concerned. I realize this is very subjective.
The tools + framework for webdev are javascript, html and css (and assets i.e. images/data). Everything else is an abstraction that has trade-offs.
Frameworks can help teams create a baseline standard. A custom framework can be something that you need to educate other developers with, better to have an external framework at times. But at the rate of churn, depending on the team and product, some frameworks makes sense and some don't. Monolithic frameworks are harder to change, micro can swap more easily.
Really in the end, all frameworks and tools are abstractions to help accelerate development, but sometimes they don't, and one case of that is constant churn. New frameworks are a healthy sign for active development but they also have a cost associated with them. Frameworks can also abstract away too much and shroud the real platform/standards which leads to lock-in. Each project and product has needs that some frameworks fit and some don't, real development/engineering is deciding what a product/project needs.
The only way we are going to build better tools is to keep building them. Complaining about the sort of cambrian explosion going on right now on web development is short sighted. Ideas need to be discovered, explored and improved. Everything needs to be challenged. This is unknown territory in many ways. It does get a little hectic and tiring at times but that's the price we pay.
The tools need to be better than what came before, rather than just different. So far I've dealt with grunt, then gulp, then webpack. None of these are appreciably better than make, they are just different and newer...
I disagree. With webpack you declare all dependencies are resolved and declared with code, instead of a separate manifest. It's a big improvement over gulp and grunt.
I don't know why people compare gulp and grunt with webpack, they solve different problems.
You don't understand what webpack is. It's a module bundler. You use webpack in conjunction with make, grunt, gulp, or any other task runner or build system.
What do you use make, grunt, or gulp for in that case? My frontend build command is just "webpack". Everything necessary is handled in webpack.config.js.
They should definitely try to do things differently. Even when the end result is the same. The reason is simple: it provides an alternate point of view of the problem. Some issues only appear when we try to do things differently. Those issues might exist in the more common approach and be completely unknown.
I think the problem isn't "too many" --- it's the fact that they're all reinventing the same things and adding significant complexity in doing so. It's an enormous waste of resources both on the part of the developers and the end-users who ultimately have to "bear the bloat".
Web development seems unusually prone to this trend, but I've seen it happen with software in general. I hypothesise that the reason for this happening to web development in particular is largely because the basic problems have already been solved long ago, so all this churn is created by people who are "oversolving the problem", having nothing else to do than to think of new --- but not necessarily better --- ways of doing it.
Introducing complexity must feel productive to a lot of people, and I suppose some derive pleasure from being able to learn about, build, comprehend, and modify such complex systems. But I don't. Making websites that require several MB of JS and the latest browser features to display a few KB of static text? I just don't see the point.
I've been building UIs for 20 years, and the tools we have now are the best I've ever had the pleasure to work with. It's more fun now than ever. More please.
That's part of the frustration for people coming from other specialties. Why are your problems so different from mine as to have a different "best" list of tools? We're both building web-based UIs. We should be using basically the same tools.
You develop for large and small screens, with either keyboard/mouse or touchscreen inputs. That's all.
The specifics are supposed to be automatically handled by preprocessing and deployment tools, or only cared for in the optimization/final polish phase.
> "Using the same standards that categorize 90% of science fiction as trash, crud, or crap, it can be argued that 90% of film, literature, consumer goods, etc. is crap."
90% is also roughly the failure rate of startups. Pareto principle?
The problem with “don’t re-invent the wheel” approach to software development is that, IMHO, software engineers are yet to invent the wheel in the first place.
The problem with that is that there are accepted standards for tooling for carpentry. Sure, there are 900 different kinds of tools, but they all solve a minimal subset of measuring, cutting, drilling, holding, joining, and smoothing.
There's no equivalent of the basic problems of carpentry in the profusion of javascript libraries. Many of the libraries written in the last year solve problems created by other libraries.
People forget that the reason Rails was such a revolution is that it took all the fifty kinds of crap that people used to build an application and made it available in one package with good defaults. The good defaults part of that is absolutely critical.
The problem is not "bad libraries", it's a complete lack of curation and direction.
Right, which we need to solve through better ways of curating projects as a community. Browsing through 20 different options in npm trying to guess which ones are good is not a scalable way to build software.
The long term answer isn't to have fewer options or barriers to entry for new frameworks. The right solution is to make better ways to browse and select between all the options we have available.
Can we curate libraries algorithmically? Or do we need people to do it? (And if so what should their tools look like?)
> The right solution is to make better ways to browse and select between all the options we have available.
I think you're missing the point. The problem is not "which library is best at x y and z", the problem is that nobody agrees on what X, Y, and Z are.
It's a definitional problem, not a curation problem. Curation is easy once you have a yardstick to measure things with (pun intended).
Again dropping back to the metaphor of woodworking, one can clearly evaluate the results of using any given tool against a thousand years of physical history - no such comparison is possible with current libraries, especially in the rat's nest of javascript, and that's fundamentally the issue.
On the other hand, a carpenter can buy a good hammer/set of chisels/block plane/circular saw - and use them for decades without cow orkers or project managers questioning their choice of tool and demanding they use completely different incompatible ones...
Imagine if every six months, your circular saw became incompatible with the version of wood you need to cut.
Meanwhile, the hammer you use is no longer supported, and breaks every time you pick it up, but using a new hammer means changing every single nail in the parts that you've already completed.
Then the job ends, and you look for a new job, they don't think you're qualified because you used the same chisel for two years, and don't think you'll know how to use the new chisel design that came out 3 months ago.
I totally get what you are saying but it seems to be to be increasingly difficult to find the good frameworks, especially since the badness of some frameworks only manifest on larger scales.
Looking at the long term life of an application, the abundance and volatility of the tools and frameworks is a nightmare. Who will find developers for ZZZZ framework in 3 years from now?
Also the fragmentation of efforts to improve the tools is a waste of resources. Instead of choosing a few directions and delivering, everyone knows better and it's doing his own version of different, but usually not better, tool. That will help anyone else? "Yes!", they will say. "I don't care", they think.
I've been a coder and have watched coders for a long time. I consistently see two trends.
As an agile guy, back in the day I wrote an Agile story tracker. Fun times. Then I saw some other Agile project management tools. Then for a while it seemed like every week or two I was getting emails asking me to evaluate yet another agile/to-do list tool.
It seemed that programmers were unable to grok the agile story concept without making their own tool to use it.
But I saw the same kind of thing in the code I wrote. I wouldn't just solve a problem; I'd solve a class of problems. Generalization was awesome! The more I generalize and account for edge cases, the more value I am creating! Woo!
Many of us programmers, myself included, are constitutionally incapable of just solving the exact problem we have using the minimal amount of code and then moving on. We confuse coding with value creation, so we build frameworks and tools out of everything. If you build a list sorter, that's okay, but if you build a 30KLOC list uber machine, that's better, right? After all, it does more. You worked harder at it.
The second thing I saw, which was even more painful to realize and accept, was that it was very easy to get "upside down" in a toolset or framework and not even be aware of what's going on.
The first time I saw it was when I was teaching a mainframe team Visual Basic, back in the 90s. We were building a simple form with a textbox and button. I had showed them the concepts and they were a smart bunch. I started the exercise, but a couple of developers were stumped.
Why?
When I walked over, the problem they had was the properties page. Sure, they got the concept of drag-and-drop. But once the button was dropped? There were like a million options in there! What was the right font size? What did this thing mean? And so on.
I thought that was pretty silly and tried to forget it. But then I noticed in my own work that I'd get sold on a new set of tools. For sake of argument let's use the old Infragistics web controls. They do everything! Amazing control and look-and-feel!
I'd drop them on a web page wanting to create a smart grid. But the grid didn't do X, and in my mind, X was what needed to happen. So I'd poke around at the help file. I'd go online. In some cases I'd tear apart the javascript and start fixing it myself. Hey, it's only web programming. I can do this.
But holy shit that took a lot of time. On my next project when I needed a grid? I dropped a HTML table in. Just added whatever functionality I needed directly from JS. Not only did it take less time, but the resulting codebase was easier to read.
Then I started watching the teams I coached. They very rarely talked about actually solving problems, or language/foundational issues. Instead they talked about tools and frameworks. This tool or framework would do this cool thing if you tweaked it like this. Joe spent 2 days trying to get Y to work.
For many, many teams, buying into the framework means buying into a complexity and cognitive overhead that's siomply not relevant to the actual problem they're trying to solve. I don't know. Maybe it makes them feel cool or something. One of the smart kids. But speaking as both a participant and an observer, it's whack.
tl;dr So sure, let a thousand flowers bloom. But your job isn't arranging flower baskets, it's helping somebody who's down feel better. You might not even need flowers at all. Stop focusing on the tools and start focusing on the solution. Then the tools will work themselves out.
This x 1000. As an additional perspective, I used to be on the board of trustees of my church when we were picking new bookkeeping software (for a church whose annual budget was less than $100K). We kept getting shown software that "handles everything for you" and eventually got strongarmed into Quickbooks (which the treasurer set up wrong) and nobody listened to me when I told them that unless they knew the finances well enough to run them with a paper spreadsheet, a checkbook and a calculator they had no business picking software.
The point of that story is that it takes a long time to properly understand a problem domain well enough to start solving problems in it at the right level of abstraction. A framework can "understand things for you" and just work if you set it up right, but the cost is that you lose the freedom to replace that framework with something smaller and lighter.
Interesting, but you're pretty spot on. Personally this has caused me great angst[0] as I tend to write the absolute minimum amount of code necessary to solve the exact problem I'm trying to solve.
I tend to wait until I've solved a problem in similar ways three[1] or so times before I generalize it.
[0] Because other developers want to solve for a more general problem.
[1] Three is such a comfortable number, isn't it?
As an aside, the author of the article is one of the authors of Tachyons—the library I consider the tool that makes me not want to die when designing web pages:
This is simply the Pareto principle (80/20) rule, and it's true of most things.
This is also true of Startups -- most of them die, but that doesn't mean they didn't add value in validated learning (positively or negatively).
Elon Musk has often stated that he thought Space X had very little odds of success, but he continued because he believed he could create value that someone else could build on.
I disagree. When more developers build the same framework, quality will always be better, because it will be better tested, more reviewed, has more knowledge, has more integrations with tools, packages, other frameworks. I really hate when effort on the same area is distributed.
When you have multiple tools instead of one, it's hard to find the best one.
This is all fine and good - but it would be nice to know which one's work well, which are robust, and which one's are 'pro level' - without have to experiment with each one.
It's really hard to tell these days.
After some experience with node.js - I'm weary to pluck anything that's not in the 'top 10' most established frameworks.
It's a feedback problem. People seek to solve problems and by doing so create new ones. Which also need solutions. That create more problems. Packaging, transpiling etc are already second order problems and there are third and fourth ones as well. This won't stop until js becomes completely unusable.
I confess to being one of the people who moans a lot, but this post might be right. I will try to moan less because the JS community has made a lot of progress. I guess the secret is not getting caught up in hype, and focusing on the real value.
Java had the same issue in the beginning. Then time and money made many disappear. Now it is Spring and JSF. The hundreds of other frameworks have largely disappeared .
You need organisation. Which is again time/money/resources.
Java had the same issue in the beginning. Then time and money made many disappear. Now it is Spring and JSF. The hundreds of other frameworks have largely disappeared .
> CrocodileJS is a Node MVC framework that lets you chew apart JavaScript
Four words in and CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks (Node is an immediate non-starter in the same vein as MongoDB). Just to give you some perspective and perhaps help you see the irony.
I know that. I wouldn't touch node with a 10 foot pole (after past experiences) and since the parent comment's framework is integrated with Node it's a non-starter.
How so? Energy consumption is far less, the raw price is much cheaper, varieties of brightnesses and Kelvin, different quality of lights, different designs for the aesthetic look.
We even have smart light bulbs -- my door light turns itself on and off at dusk and dawn.
Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the other end of the spectrum, the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time.
I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration).
Of course, I have no numbers to back any of this up - it's just an observation (one skewed by personal experience, no doubt).
[1] https://en.wikipedia.org/wiki/Herfindahl_index