11 ms·

Too Many Tools and Frameworks (2015)

274 points by moeamaya 10y ago

swyman 10y ago
Ultimately the responsibility to pick reliable tools lies with the carpenter
- jaggederest 10y ago
  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.
  - josephg 10y ago
    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?)
    - jaggederest 10y ago
      > 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.
- keyle 10y ago
  True but most often the carpenter is misinformed by crowds or large corporation pushing their tools as "the best in the business".
  - KaiserPro 10y ago
    only if they are an arse, and can't figure out changes in quality of work.
- bigiain 10y ago
  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...
  - michaelchisari 10y ago
    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.
    - usgroup 10y ago
      > Imagine if every six months, your circular saw became incompatible with the version of wood you need to cut. This made me lol, thank you ... Those poor carpenters. Thousands of years of metaphorical abuse.
mgalka 10y ago
> "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?
- KerryJones 10y ago
  Yep, you just very concisely explained a comment I just wrote (I didn't see this one).
thomasnno 10y 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.
bungle 10y ago
Light bulbs have not improved, they have become worse, and are designed to fail.
- reubano 10y ago
  The parent is right after all. Just do a search for "the 100 yr light bulb".
  - noselasd 10y ago
    "planned obsolescence" for lightbulbs is not a recent thing though; https://en.wikipedia.org/wiki/Phoebus_cartel https://en.wikipedia.org/wiki/Phoebus_cartel
- KerryJones 10y ago
  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.
michaelchisari 10y ago
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.
- highmastdon 10y ago
  @michaelchisari honest question: are you a bit discontent with the fact that you don't know angular framework?
  - michaelchisari 10y ago
    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. Why do you ask?
- 59nadir 10y ago
  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.
dperfect 10y ago
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). [1] https://en.wikipedia.org/wiki/Herfindahl_index https://en.wikipedia.org/wiki/Herfindahl_index
- inopinatus 10y ago
  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?
- usgroup 10y ago
  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.
  - vog 10y ago
blowski 10y ago
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.
drawkbox 10y ago
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.
asimuvPR 10y ago
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.
- douche 10y ago
  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...
  - asimuvPR 10y ago
    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.
  - austinpray 10y ago
    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.
    - vonmoltke 10y ago
      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.
  - piotrkaminski 10y ago
    On the contrary: when looking for a global maximum you will almost certainly have to pass through local minima, so different _is_ good in this case.
niftylettuce 10y ago
I'm building a better JS framework https://github.com/crocodilejs/crocodile-node-mvc-framework https://github.com/crocodilejs/crocodile-node-mvc-framework - release v1.0.0 comes out soon, join in Slack at http://slack.crocodilejs.com/ http://slack.crocodilejs.com/
- symlinkk 10y ago
  lol, this is exactly what OP is talking about
- DSteinmann 10y ago
  > 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.
  - enraged_camel 10y ago
    Node is an application runtime environment, not a framework. There are frameworks written on top of Node, such as ExpressJS. http://www.javaworld.com/article/2079190/scripting-jvm-languages/6-things-you-should-know-about-node-js.html http://www.javaworld.com/article/2079190/scripting-jvm-langu...
    - DSteinmann 10y ago
      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.
      - deleted 10y ago
        [deleted]
    - mastazi 10y ago
      GP said: > CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks in this context, "framework" seems to refer to CrocodileJS, not Node.
AdrianB1 10y ago
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.
- usgroup 10y ago
  Yes then at some point we all end up using ML, Lisp or C, and then it all starts again :)
KerryJones 10y ago
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.
joelhooks 10y ago
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.
- rekshaw 10y ago
  Can you provide a shortlist of the tools you use?
  - progx 10y ago
    The list won't solve any of your specific problems. I had a much better list, then the previous Poster, because it solve my problems the best way. Did you need my list now too? I am absolutely sure, that somebody else had a better list.
    - vonmoltke 10y ago
      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.
- amelius 10y ago
  Except now we have to target 3 different mobile platforms, the web, and possibly 3 different native desktop environments. Where is the progress in that?
  - leppr 10y ago
    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.
  - spdionis 10y ago
    That we actually can target all of them more or less easily?
hoodoof 10y ago
The solution - don't use them.
Walkman 10y ago
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.
satyajeet23 10y ago
(DEVELOPARALYSIS) [https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-of-developaralysis/ https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-of...]
DanielBMarkham 10y ago
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.
avidprotoolsusr 10y ago
I often see some of us as programmers are afraid of consolidation, we sometimes think it will destroy openness. We do have a ton of frameworks. I just wish that some of the people would come together and plan and created better, less scattered versions of what we have.
fauigerzigerk 10y ago
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.
andres_kytt 10y ago
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.
jomamaxx 10y ago
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.
heinbehrens 10y ago
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 .
heinbehrens 10y ago
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.
dataharry 10y ago
Wake me up when the good ones are created then
userbinator 10y ago
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. Related: http://countercomplex.blogspot.com/2014/08/the-resource-leak-bug-of-our.html http://countercomplex.blogspot.com/2014/08/the-resource-leak... and discussion https://news.ycombinator.com/item?id=8679471 https://news.ycombinator.com/item?id=8679471
sotojuan 10y ago
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: http://tachyons.io/ http://tachyons.io/
- cel1ne 10y ago
  Tachyons is amazing, so I ported it for react-native: https://github.com/tachyons-css/react-native-style-tachyons https://github.com/tachyons-css/react-native-style-tachyons <View cls="ba jcfs pa2"> <Text cls="white tc"> Something </Text> </View>
dkarl 10y ago
As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it can be done as a library than as a framework. We look for libraries that humbly strive to coexist with whatever other libraries we need. The few times I've dipped into web UI Javascript, I've felt like the developers of UI "frameworks" share this mindset much more than the people using their work; often they'll explicitly point out that the tool they've built (such as backbone.js) is a library rather than a framework, while the people recommending it to me will say "no no, it's a framework," meaning "no no, it's way better than just a library." Is that an expression of a real difference between back-end and web UI code, or is it just different phases in the tide of opinion?
- weberc2 10y ago
  I agree. I program in quite a few languages, but Go is my favorite when it comes to a low-bullshit ecosystem. There are probably too many web frameworks, but the standard HTTP library seems to have the bulk of the marketshare.
- morgante 10y ago
  I'm pretty sure you're just playing with words here. One of the most common complaints is that the biggest web tools are libraries, not frameworks. React, for example, is very emphatically not a framework. To develop any reasonably sized application, you need to bring in a number of other libraries as well (such as Redux and/or Apollo).
  - dkarl 10y ago
    It isn't just words — the words reflect people's expectation that a framework determines quite a lot about your design and approach. It's a system and a way of programming you assimilate into. A library tries to help you do something while dictating as little as possible about your overall application design. I think it's very interesting that even though the expert and experienced programmers who create things like backbone.js and React have openly and explicitly designed them not to be frameworks, people continue to call them frameworks, and not disparagingly. There seems to be a huge appetite for frameworks. From the outside (and definitely projecting my own inexperience) I would guess that a lot of people feel lost architecting a web UI from scratch. They don't want building blocks. They want a way, a path to follow. A lot of server programmers felt the same way twenty years ago. Adopting a framework meant giving up freedom that they didn't want in the first place because they didn't know what to do with it. But I'm coming at it from a very outside/inexperienced perspective, so I feel like I should leave it as a question rather than a comment. What do you think? Why are frameworks considered such a good thing in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?
dreta 10y ago
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.
vanillajs 10y ago
>.io domain why am i not surprised
- deleted 10y ago
  [deleted]

274 points by moeamaya 10y ago

swyman 10y ago

Ultimately the responsibility to pick reliable tools lies with the carpenter

jaggederest 10y ago
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.
- josephg 10y ago
  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?)
  - jaggederest 10y ago
    > 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.
keyle 10y ago
True but most often the carpenter is misinformed by crowds or large corporation pushing their tools as "the best in the business".
- KaiserPro 10y ago
  only if they are an arse, and can't figure out changes in quality of work.
bigiain 10y ago
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...
- michaelchisari 10y ago
  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.
  - usgroup 10y ago
    > Imagine if every six months, your circular saw became incompatible with the version of wood you need to cut. This made me lol, thank you ... Those poor carpenters. Thousands of years of metaphorical abuse.

mgalka 10y ago

> "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?

KerryJones 10y ago
Yep, you just very concisely explained a comment I just wrote (I didn't see this one).

thomasnno 10y 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.

bungle 10y ago

Light bulbs have not improved, they have become worse, and are designed to fail.

reubano 10y ago
The parent is right after all. Just do a search for "the 100 yr light bulb".
- noselasd 10y ago
  "planned obsolescence" for lightbulbs is not a recent thing though; https://en.wikipedia.org/wiki/Phoebus_cartel https://en.wikipedia.org/wiki/Phoebus_cartel
KerryJones 10y ago
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.

michaelchisari 10y ago

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.

highmastdon 10y ago
@michaelchisari honest question: are you a bit discontent with the fact that you don't know angular framework?
- michaelchisari 10y ago
  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. Why do you ask?
59nadir 10y ago
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.

dperfect 10y ago

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). [1] https://en.wikipedia.org/wiki/Herfindahl_index https://en.wikipedia.org/wiki/Herfindahl_index

inopinatus 10y ago
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?
usgroup 10y ago
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.
- vog 10y ago

blowski 10y ago

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.

drawkbox 10y ago

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.

asimuvPR 10y ago

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.

douche 10y ago
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...
- asimuvPR 10y ago
  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.
- austinpray 10y ago
  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.
  - vonmoltke 10y ago
    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.
- piotrkaminski 10y ago
  On the contrary: when looking for a global maximum you will almost certainly have to pass through local minima, so different _is_ good in this case.

niftylettuce 10y ago

I'm building a better JS framework https://github.com/crocodilejs/crocodile-node-mvc-framework https://github.com/crocodilejs/crocodile-node-mvc-framework - release v1.0.0 comes out soon, join in Slack at http://slack.crocodilejs.com/ http://slack.crocodilejs.com/

symlinkk 10y ago
lol, this is exactly what OP is talking about
DSteinmann 10y ago
> 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.
- enraged_camel 10y ago
  Node is an application runtime environment, not a framework. There are frameworks written on top of Node, such as ExpressJS. http://www.javaworld.com/article/2079190/scripting-jvm-languages/6-things-you-should-know-about-node-js.html http://www.javaworld.com/article/2079190/scripting-jvm-langu...
  - DSteinmann 10y ago
    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.
    - deleted 10y ago
      [deleted]
  - mastazi 10y ago
    GP said: > CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks in this context, "framework" seems to refer to CrocodileJS, not Node.

AdrianB1 10y ago

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.

usgroup 10y ago
Yes then at some point we all end up using ML, Lisp or C, and then it all starts again :)

KerryJones 10y ago

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.

joelhooks 10y ago

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.

rekshaw 10y ago
Can you provide a shortlist of the tools you use?
- progx 10y ago
  The list won't solve any of your specific problems. I had a much better list, then the previous Poster, because it solve my problems the best way. Did you need my list now too? I am absolutely sure, that somebody else had a better list.
  - vonmoltke 10y ago
    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.
amelius 10y ago
Except now we have to target 3 different mobile platforms, the web, and possibly 3 different native desktop environments. Where is the progress in that?
- leppr 10y ago
  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.
- spdionis 10y ago
  That we actually can target all of them more or less easily?

hoodoof 10y ago

The solution - don't use them.

Walkman 10y ago

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.

satyajeet23 10y ago

(DEVELOPARALYSIS) [https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-of-developaralysis/ https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-of...]

DanielBMarkham 10y ago

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.

avidprotoolsusr 10y ago

I often see some of us as programmers are afraid of consolidation, we sometimes think it will destroy openness. We do have a ton of frameworks. I just wish that some of the people would come together and plan and created better, less scattered versions of what we have.

fauigerzigerk 10y ago

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.

andres_kytt 10y ago

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.

jomamaxx 10y ago

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.

heinbehrens 10y ago

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 .

heinbehrens 10y ago

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.

dataharry 10y ago

Wake me up when the good ones are created then

userbinator 10y ago

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. Related: http://countercomplex.blogspot.com/2014/08/the-resource-leak-bug-of-our.html http://countercomplex.blogspot.com/2014/08/the-resource-leak... and discussion https://news.ycombinator.com/item?id=8679471 https://news.ycombinator.com/item?id=8679471

sotojuan 10y ago

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: http://tachyons.io/ http://tachyons.io/

cel1ne 10y ago
Tachyons is amazing, so I ported it for react-native: https://github.com/tachyons-css/react-native-style-tachyons https://github.com/tachyons-css/react-native-style-tachyons <View cls="ba jcfs pa2"> <Text cls="white tc"> Something </Text> </View>

dkarl 10y ago

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

weberc2 10y ago
I agree. I program in quite a few languages, but Go is my favorite when it comes to a low-bullshit ecosystem. There are probably too many web frameworks, but the standard HTTP library seems to have the bulk of the marketshare.
morgante 10y ago
I'm pretty sure you're just playing with words here. One of the most common complaints is that the biggest web tools are libraries, not frameworks. React, for example, is very emphatically not a framework. To develop any reasonably sized application, you need to bring in a number of other libraries as well (such as Redux and/or Apollo).
- dkarl 10y ago
  It isn't just words — the words reflect people's expectation that a framework determines quite a lot about your design and approach. It's a system and a way of programming you assimilate into. A library tries to help you do something while dictating as little as possible about your overall application design. I think it's very interesting that even though the expert and experienced programmers who create things like backbone.js and React have openly and explicitly designed them not to be frameworks, people continue to call them frameworks, and not disparagingly. There seems to be a huge appetite for frameworks. From the outside (and definitely projecting my own inexperience) I would guess that a lot of people feel lost architecting a web UI from scratch. They don't want building blocks. They want a way, a path to follow. A lot of server programmers felt the same way twenty years ago. Adopting a framework meant giving up freedom that they didn't want in the first place because they didn't know what to do with it. But I'm coming at it from a very outside/inexperienced perspective, so I feel like I should leave it as a question rather than a comment. What do you think? Why are frameworks considered such a good thing in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?

dreta 10y ago

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.

vanillajs 10y ago

>.io domain why am i not surprised

deleted 10y ago
[deleted]