4 ms·

At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" librar

by Renner1 10y ago

At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.

shados 10y ago
API compatible or near compatible drop in replacements are a good thing though. The way we can have new things without needing to rewrite everything. The only issue with this one is the lack of context API, which is needed for a lot of third party integrations, like react-redux. If it wasn't for that, it wouldn't be a problem at all.
- merrywhether 10y ago
  > it wouldn't be a problem at all I have trouble believing this is true in the long-run. There are several examples that seem contrary to this idea. Lodash was supposed to be a drop-in replacement for underscore, and that was fine and all until contributors felt like they had to duplicate any new features into both libraries. On the bright side, this lead to their upcoming merger, but not without years of wasted effort duplicating work and ink spilled arguing over which was better. You could argue that underscore could have been more willing to merge in more-performant implementations (though I think they preferred readability over speed), but it seems like this fork-first mentality in the JS world somehow makes that almost looked down upon. Others like Zepto or other jQuery-alikes seem to reach moderate uptake at best but don't necessarily move the community forward either. Ultimately it seems like the best you can hope for is to get enough attention / stir up enough of a hornet's nest / make dual-contributors lives hard enough to then get merged back in to the original library, and it seems like this is much more pronounced in the JS community[0]. But looking at Node vs IO, CoffeeScript vs JS, or other like-X-but-better situations[1], it sure seems like more community input into and improvement of the already existing frameworks would go a long way. 0: I'm totally willing to admit that JS is one of the things I spend more time doing so I just might notice it more. 1: I know there are nuances to these situations, but I'm being a little reductionist, and they were still stand up to the point.
- rhizome 10y ago
  A naive question: how often are replacements ever dropped in?
deleted 10y ago
[deleted]
SkyMarshal 10y ago
Creating new things is sometimes the only or most efficient way of experimenting with new ideas, features and techniques. And if they're really good, other libraries or frameworks can consider implementing them. The beauty of open source.
sangnoir 10y ago
> we are only fueling the flames of javascript fatigue The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do. If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either. It took me all of 30 seconds to skim the home page and to conclude "hmm, I don't need this now", but I've filed it at the back of my mind should I require it some day (I might not remember the name then, but I'll be able to figure out the search keywords). > We need to stop fragmenting and start doubling down on existing libraries. I reject this sentiment. You can't force people to contribute to projects they have no passion for. You also can't prevent people from scratching their own itch and registering a domain for their slightly different flavor-of-the-week JS project. Best you can do is ignore them or support them. The undeserving will wither eventually, you do not owe any project your attention.
- knite 10y ago
  Member of the peanut gallery here, and I fully agree with Renner1. I occasionally do front end development work, and the pace of change makes life very difficult. Imagine someone who last wrote a Python/Ruby/C/Java application 5 years ago - they could hit the ground running and learn a few new best practices and tools in 1-2 new weeks. Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do. It feels like the JS landscape is changing so fast that keeping up with things is a full-time job.
  - jdavis703 10y ago
    This situation is way better than everyone having an in-house "library" that you have to learn, which is what it seemed like what happened a few years ago (it would be something in house, layered on top of jQuery or whatever).
  - gecko 10y ago
    I actually just went through this myself. I had last done frontend work in about 2010, maybe a little in 2011, and realized my skill set was probably getting stale, so I asked my boss if I could do frontend for a bit, with the understanding that I'd underperform. He said sure. I've left and returned to C++ a couple of times. Same for Java. Most recently, I did some Ruby dev in 2015 after last doing it in 2006. In all of these instances, while there was some library and language churn, it was pretty easy to pick up. C++ lambdas are just cleaner syntax for functors, and the better optimizers and reworked libraries mean they're more widely usable, but no big deal. Java has a streaming library now and lambdas of its own, but it's largely syntax sugar, and even if Grade has largely replaced Maven, the concepts and issues are roughly identical. Bundler was new to me, but why it existed was transparent and its relationship to gems was clear, so only an hour or so of work was enough to get me up to speed. I assumed web work would be similar. I felt like I was relearning from scratch. jQuery was gone; use anything else. There are several different build systems, all slightly incompatible with each other, to replace YUI compressor and Closure. Prototypes are gone, classes are in. Underscore is gone, and a richer class library is in, but it's not widely supported, so you have to cross compile, for which you need source maps. Some best practices became worst (shove all the JS into one file is the new hotness), but apparently may go to worst (fracturing is better due to HTTP/2 push). I have actually seen this before: Windows, as it switched from the 3.1/95 series to the COM-heavy NTs, had churn like this. So did Carbon to Cocoa, and arguably Cocoa prior to 10.3 and after, and again once ARC was introduced. But those were single events, whereas this seems, from where I sit, to be a sustained burn.
BinaryIdiot 10y ago
Alternatively we need to start making optional frameworks. Essentially a way to do many of the usual things you use a framework for (like model binding) but will work, without changing the code, when using just about any framework. I hate taking the basic things that are not hugely different in concept and workflow but end up using very different code so I can't port it between frameworks. Working on the start of this in my msngr.js library (shameless plug) because I would like to use it but also because I think it's important. A new framework every couple of weeks is daunting but okay. Not being able to reuse code between them is awful.

by Renner1 10y ago

shados 10y ago

API compatible or near compatible drop in replacements are a good thing though. The way we can have new things without needing to rewrite everything. The only issue with this one is the lack of context API, which is needed for a lot of third party integrations, like react-redux. If it wasn't for that, it wouldn't be a problem at all.

merrywhether 10y ago
> it wouldn't be a problem at all I have trouble believing this is true in the long-run. There are several examples that seem contrary to this idea. Lodash was supposed to be a drop-in replacement for underscore, and that was fine and all until contributors felt like they had to duplicate any new features into both libraries. On the bright side, this lead to their upcoming merger, but not without years of wasted effort duplicating work and ink spilled arguing over which was better. You could argue that underscore could have been more willing to merge in more-performant implementations (though I think they preferred readability over speed), but it seems like this fork-first mentality in the JS world somehow makes that almost looked down upon. Others like Zepto or other jQuery-alikes seem to reach moderate uptake at best but don't necessarily move the community forward either. Ultimately it seems like the best you can hope for is to get enough attention / stir up enough of a hornet's nest / make dual-contributors lives hard enough to then get merged back in to the original library, and it seems like this is much more pronounced in the JS community[0]. But looking at Node vs IO, CoffeeScript vs JS, or other like-X-but-better situations[1], it sure seems like more community input into and improvement of the already existing frameworks would go a long way. 0: I'm totally willing to admit that JS is one of the things I spend more time doing so I just might notice it more. 1: I know there are nuances to these situations, but I'm being a little reductionist, and they were still stand up to the point.
rhizome 10y ago
A naive question: how often are replacements ever dropped in?

deleted 10y ago

[deleted]

SkyMarshal 10y ago

Creating new things is sometimes the only or most efficient way of experimenting with new ideas, features and techniques. And if they're really good, other libraries or frameworks can consider implementing them. The beauty of open source.

sangnoir 10y ago

> we are only fueling the flames of javascript fatigue The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do. If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either. It took me all of 30 seconds to skim the home page and to conclude "hmm, I don't need this now", but I've filed it at the back of my mind should I require it some day (I might not remember the name then, but I'll be able to figure out the search keywords). > We need to stop fragmenting and start doubling down on existing libraries. I reject this sentiment. You can't force people to contribute to projects they have no passion for. You also can't prevent people from scratching their own itch and registering a domain for their slightly different flavor-of-the-week JS project. Best you can do is ignore them or support them. The undeserving will wither eventually, you do not owe any project your attention.

knite 10y ago
Member of the peanut gallery here, and I fully agree with Renner1. I occasionally do front end development work, and the pace of change makes life very difficult. Imagine someone who last wrote a Python/Ruby/C/Java application 5 years ago - they could hit the ground running and learn a few new best practices and tools in 1-2 new weeks. Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do. It feels like the JS landscape is changing so fast that keeping up with things is a full-time job.
- jdavis703 10y ago
  This situation is way better than everyone having an in-house "library" that you have to learn, which is what it seemed like what happened a few years ago (it would be something in house, layered on top of jQuery or whatever).
- gecko 10y ago
  I actually just went through this myself. I had last done frontend work in about 2010, maybe a little in 2011, and realized my skill set was probably getting stale, so I asked my boss if I could do frontend for a bit, with the understanding that I'd underperform. He said sure. I've left and returned to C++ a couple of times. Same for Java. Most recently, I did some Ruby dev in 2015 after last doing it in 2006. In all of these instances, while there was some library and language churn, it was pretty easy to pick up. C++ lambdas are just cleaner syntax for functors, and the better optimizers and reworked libraries mean they're more widely usable, but no big deal. Java has a streaming library now and lambdas of its own, but it's largely syntax sugar, and even if Grade has largely replaced Maven, the concepts and issues are roughly identical. Bundler was new to me, but why it existed was transparent and its relationship to gems was clear, so only an hour or so of work was enough to get me up to speed. I assumed web work would be similar. I felt like I was relearning from scratch. jQuery was gone; use anything else. There are several different build systems, all slightly incompatible with each other, to replace YUI compressor and Closure. Prototypes are gone, classes are in. Underscore is gone, and a richer class library is in, but it's not widely supported, so you have to cross compile, for which you need source maps. Some best practices became worst (shove all the JS into one file is the new hotness), but apparently may go to worst (fracturing is better due to HTTP/2 push). I have actually seen this before: Windows, as it switched from the 3.1/95 series to the COM-heavy NTs, had churn like this. So did Carbon to Cocoa, and arguably Cocoa prior to 10.3 and after, and again once ARC was introduced. But those were single events, whereas this seems, from where I sit, to be a sustained burn.

BinaryIdiot 10y ago

Alternatively we need to start making optional frameworks. Essentially a way to do many of the usual things you use a framework for (like model binding) but will work, without changing the code, when using just about any framework. I hate taking the basic things that are not hugely different in concept and workflow but end up using very different code so I can't port it between frameworks. Working on the start of this in my msngr.js library (shameless plug) because I would like to use it but also because I think it's important. A new framework every couple of weeks is daunting but okay. Not being able to reuse code between them is awful.