I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the browser experience on-par with native? How do all these things interact, and what about all the other factors that I'm not smart enough to see, but usually someone on HN points out for me?
But no, I never get to read that, just complaints about how the whole community is dumb. Really? That seems unlikely. I don't believe this is pointless tech churn, akin to fashion. It really feels to me, at least, that there is a direction that the tooling is heading. I'm not sure what it is, but I feel like if that's where these conversations were focused (instead of just rejecting the current state of things) we could figure it out.
Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.
With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty?
Where does the churn end if it's not pointless?
Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly implemented that most everyone tries to abstract it away at some point, and a language that is universally regarded as one of the worst ever.
Is that what you build on for the future? Cause then I do see it being pointless tech churn because your fundamental building blocks are too seriously flawed.
If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.
If you had such a thing this thread of conversations wouldn't even be happening. I sincerely hope that someone smarter than me comes up with that (yes, Java was a close but no cigar) and we gravitate away from the morass we have now.
I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things, but setting that aside:
The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind. It also represents one of the most open and portable computing environments ever developed. It incubated a revolutionary and indispensable app for indexing, searching, and retrieving an unprecedented staggering corpus of human knowledge (Google.com); apps that have enabled hundreds of millions of people to effortlessly publish their writing, videos, pictures, etc globally and instantly (Twitter, YouTube, WordPress, Blogger, etc etc); apps that make it trivial to find most of the people you have ever known and to collapse time and space to communicate with them (Facebook, Gmail, etc etc); apps that enable you to select virtually any product imaginable and have it delivered, usually within 24 hours if needed (Amazon, Ebay, etc etc); not to mention probably millions of other more obscure apps to handle amazingly specific mundanities of office life, travel, entertainment, citizenship, finance, etc etc etc.
To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point.
It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music.
I can't speak for the OP but I think that's roughly what they were getting at.
(Also, side note, Tim Berners Lee may perhaps have conceived the web as a place for documents, but he also seems to have since then embraced it as an application platform, not that his opinion or original vision should in any way confine what the web becomes. http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ )
I wish I would upvote you 100 times. I've been a web developer over 20 years now. This attitude, that the web is unsuitable for applications, was understandable 15 years ago at the birth of web apps, but it doesn't make any sense today.
People need to realize there's never been a platform like the web in terms of portability and accessibility. Comparing the web to GUI toolkits is like saying that comparing Linux desktops to Mac OS X—Linux environments can never have the polish of OS X because Apple controls the entire stack. Similarly, a GUI toolkit can only be as cross-platform as the vendor makes (which is historically pretty terrible for all cross-platform GUI toolkits). The web is not only a standard, but a standard whose implementation is the price of entry for all new devices.
Furthermore, everyone complaining about the web's shortcomings doesn't have the whole picture—in fact the most difficult thing about a standard of this size is that no single individual or organization has the whole picture of what the standard supports. Sure the web was designed for simple documents and evolved into something for which it was never intended, why is this a bad thing? The fact is that you can never replace the web because A) there is no human power great enough to force adoption, it can only happen by serendipity (just like the web) and B) by the time you were done you would have a whole different set of warts that everyone would complain about. People would do well to remember Gall's Law before condemning web-as-app-platform.
> I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things
Would everyone is discussing the high quality of the Emperor's new clothes, is it productive to point out that he is, in fact, naked as a jaybird?
At some point we have to face up to the simple truth that JavaScript, the DOM, XML and HTML-as-she-is-written are bad. The people who assembled them over time aren't evil, or even generally incompetent: there are historical reasons for almost all of the cruft. But that doesn't mean that it's not horribly, horribly crufty, that is is objectively bad and in poor taste.
> The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind.
That's the logical fallacy known as argumentum ad populum, i.e. arguing that because something is popular is is correct.
> To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point.
It is aggressively contemptuous because the current web stack deserves contempt. That is the point.
> It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music.
No, it's more like complaining that each of the interesting people is wearing a blindfold, earmuffs & a gag, with a hobble to prevent him from getting within arm's reach of anyone else and can communicate only by reaching out with a stick or probe and tapping out Morse code messages on other's arms. Sure, all those impressive people are doing a bang-up job of overcoming the absurd limitations of the insane party, but that doesn't make the party one bit less insane.
Wanna back up that beautiful rhetoric with some actual objective reasoning as to why; HTMl, Javascript, the DOM are "bad" and some ideas on the way forward?
It is "objectively" "bad" because if you bring javascript up in certain social circles involving programmers everyone huffs and puffs. I've heard people time after time who've never stepped foot out of a Java IDE complain about how hard it was for them to write something "simple" and "basic" in javascript. Not to claim that there is any real veracity in the wisdom of the crowd, but there are hundreds of thousands of programmers writing working, functional, useful apps in javascript every damn day. People can say that fact is DESPITE the language features but these people ignore that if you want to actually reach customers you have to use the most popular runtime of all time - the browser.
Being unable to have a conversation about the ecosystem because the language isn't to your liking or preferences speaks to me of a closed-off mindset, which as everyone knows is a great trait for programmers to have /s.
Monty Python explains the foundation of frontend web development better than anyone.
"When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England."
> With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty?
Well, WebAssembly is on the way, so you won't have to use JavaScript. WebGL means you could, I guess, skip over the DOM entirely if you wanted to. None of this is fantastic, of course, but it's where we are.
Programs that people can download on demand existed, and still exist, yet the web is more popular. It's cross-platform, you don't have to install anything, updates are instant. What cross-platform UI are you going to use to address Windows, Mac, iOS and Android together?
To put it more succinctly, the "truth and beauty" for me is that it works, and it works today. I'm far happier iterating on that than noodling around imagining the perfect code execution environment that, as far as I can see, has no hope of existing any time soon.
> Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications
At this point, this is argument is 100% false. Browsers of today aren't the browsers of the 90s. Chrome came out in 2008 and has ALWAYS been designed to run applications, and an entire operating (ChromeOS) is based on the idea that the browser isn't just a system built for viewing linked documents, but a valid application platform.
That would actually be a very awful future. I like a linked web full of text. Flashy this and flashy that and app for this and app for that is all blah. Most things don't actually need to be apps.
The "fundamental building blocks are too flawed" argument is so strange to me. Too flawed for what? To become, by far, the most popular platform in history for running applications? Because it's already done that.
This is a case of the evidence not fitting the theory well, so people complain about the evidence. If the browser/DOM/HTML/JS ecosystem "technically" is terrible, but in practice dominates the competition, then there is something about it that is better. This is not a fallacy, but a simple supply and demand argument.
> If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.
> I don't believe this is pointless tech churn, akin to fashion.
This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists.
But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy.
> It really feels to me, at least, that there is a direction that the tooling is heading.
It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.
Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages).
If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the one who will need to maintain your code (read: you in 3 months).
If you're knowledgable enough to know that your use-case doesn't work with the newer tools, then more power to you. But the productivity gains from moving away from your jQuery spaghetti code to one of the more managed frameworks is well worth the rewrite time.
I don't know much about going from Angular to React, or Backbone to Angular though.... the choice of framework is likely dependent on what kind of user interactions dominate your app and subjective comfort.
But if you're careful, you can actually transition apps slowly over to Angular and I assure you, you could get rid of so much of your custom-written (probably not well tested) DOM management code it's not even funny.
You know, if people approached web programming like actual programming, with layers of abstraction, there wouldn't be spaghetti code in the first place, and one could move to a different framework as needed.
But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React.
Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now.
It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently.
The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alone there was Struts, WebWork, Wicket, Tapestry, JSF, Spring MVC, and countless others, each one sucking more than the other. They are all pretty much dead now because people realized the insanity of trying to build a GUI using a page request based approach.
This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).
The attempts to compile down to JS is the best we can currently do, which is why the best and most complex JavaScript applications that have ever been made have been done this way, but obviously a native solution will be the better solution.
The best bet would be an intermediate layer, a kind of JVM for the web, on which a thousand languages could run. That is bound to be a long way out though, so we have at least a few more years of pointless JavaScript framework churn.
> [Javascript] simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).
Wrapping a browser instead of using one directly doesn't make your application run in a non-browser runtime environment.
And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.
Interesting point of view, considering that people are building javascript desktop applications, server applications, embedded applications, web (browser) applications, and what not.
I think PHP is a better analogy than early-2000s Java/.NET. Those latter technologies were largely enterprise driver, but the PHP ecosystem used to be more like today's JavaScript ecosystem. PHP a Blub[1] language, like JavaScript, which attracts inexperienced developers because it seems easy and has widespread support from hosting platforms. Inexperienced developers tend to reinvent the wheel (badly). One major difference is that PHP has a standard library that does almost everything, whereas JavaScript needs insane numbers of libraries for a typical production system (in my case, 5 explicit dependencies create a tree of ~300 packages).
> This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications.
I agree, and Facebook (Flow), Google (Dart, TypeScript, and probably others), and Microsoft (TypeScript), agree with us.
> The best bet would be an intermediate layer
See: WebAssembly[2], the successor to asm.js (sometimes called "the bytecode for the web").
I think you've nailed it. Web programming in javaland was verbose but relatively straightforward until about 2004, maybe a little earlier, when frameworks exploded. I'm not sure the frameworks themselves were worse than what preceded then - Struts2 was, in my opinion, an improvement over the original Struts. But I do recall hating web programming for a few years, wanting to leave and do something else (in a way, I did, I got a job writing java code to interact with CPLEX, and other developers handled the webapp stuff, so I was able to just mainly write straightforward Java, which I still don't think is such a bad language, it was the framework bloat that I disliked). The reason was doing very simple things had become mind numbingly difficult, and you had to wade through massive amounts of configuration and framework documentation (or code, since documentation often didn't exist for your specific issue) to do relatively simple things. The Java web programming cookbook became relatively obsolete, because everything was now handle by a framework that promised to make things simpler, but (often due to churn) massively increased the overhead.
Interestingly, it was, as you've pointed out, never resolved. Instead, it all became obsolete. I personally left javaland and started writing with Rails (even the non-web stuff I generally started using Python rather than java).
I suspect that we're heading down that road again. I think the modern javascript frameworks are the product of very intelligent and talented people, but my gues is that something interesting and "unanticipated" will sweep this all aside.
To risk a prediction, I think that other languages transpiled to isomorphic javascript will provide a new approach that will allow excellent languages like ruby and python to be used to write an entire web app again.
Until then? I wish I'd had the conviction to avoid MVC frameworks in the early 2000s. It's easy to feel like you're doing things the "old way", but I wasted a lot of time chasing java frameworks only to abandon the entire enterprise a year or two later… of course, it wasn't entirely my decision, it's hard to go against the grain, since you're rarely the only developer on a team.
> The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).
I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something they think they have to because 'all the cool kids' are.
This discussion is often brought up in relation to React/Redux/Babel/Webpack, and people thinking they have to completely master all of them to start making websites, when the reality couldn't be further from the truth.
Twitter had an amusing quip of the topic last week:
> If you’re feeling overwhelmed by Slack or React (judging by the HN front page this week), I politely suggest you re-evaluate your life.
> I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something 'all the cool kids' are.
There may be that. There's also:
a) Some of us are old enough to have mortages/kids/parents to support/houses needing renovation/desire a balanced life. We value skills that stay useful, and don't have the free time to keep learning variants of the same again and again*
b) Companies we work at/for value stability. They look at IT choices on a 5+year horizon; they don't have VC money to burn to 'rewrite' when JavaScript framework X no longer works.
Which am I more likely to get sacked for? 1) Not using the cool thing and us missing out, or 2) using the cool thing and having to explain in 18 months time that we need another $20,000 to rewrite it into the Next Cool Thing?
Before you write us off, please do a 360 and see what the field looks like from other perspectives.
* I didn't say 'don't have time to learn'. We learn - but what we learn is evaluated carefully, and we have a much wider field to learn (Programming/Management/PM/Negotation - just a few of the core work-focused skills)
Why is everyone so anxious about this? That's the part that confuses me. When we introduced a library for a new project (at a Big Old Media Company with a team varying from interns, to working-70-hours-a-week millennials, to 9-5 family people) it was fine. If someone had something to learn about one of the 5 APIs, they read the entire library documentation (which takes like 20 minutes) or just turned around and asked someone.\
I'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.
Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc.
A few questions:
* What is the projected lifetime of the new project?
* Will the code be updated continuously (vs write once & freeze)?
* What does your ecosystem around React look like?
* What library/framework were you using before which you replaced with React?
* Have yoiu committed to using React on new projects for the next.. 24 months?
It'd be great to learn more, as it sounds like a non-Facebook scale project, i.e. more relevant to most of us...
AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.
>expectation to use latest and greatest and be future-proof
In javascript (just like in any other programming language) you generally get one or the other.
You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while.
People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something?
There is nothing wrong with using mature systems, and that's why I personally feel all of this "javascript fatigue" is self inflicted. If it is going to be a project you write once then don't touch for 5 years, maybe don't use react 0.15.beta-4 as your library of choice...
The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use one that was pure JS.
I quite like writing JS and have done on and off for over 17 years, I just don't understand the constant and wilful reinvention and fragmentation in front end development.
That sounds like your developer's problem, not the technology's problem.
Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?
Given how difficult it can be to get past HR keyword filters when applying for a new job ("Oh we need a candidate with gulp experience, not grunt."), I can see how folks are fearful that they aren't using the "right" technologies. It's insanity.
It wasn't a single developer, it was a subset culture in the team of frontend developers. Those 2 examples were 2 different devs.
I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?
I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else.
I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web dev, I can tell you my experience was like turning on the lights after struggling in the dark.
Basically what I found is that web app development was designed to work great in specific ways. If you don't know this and try to get it to work in a way that it was never meant to, you're gonna have a bad time. Sadly, every front end framework and many JavaScript libraries fall into this category. They focus on bending the natural web development paradigm into some other form. Which one will "win"? None - there's no right way to do something wrong. The real question is when we will stop falling for the pitch of the snake oil salesmen.
I assure you, there is no functionality that any of the frameworks bring that does not already exist and can be implemented in much simpler, maintainable and architecturally sound ways. Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples.
Another reason we are inundated with poor frameworks is there is no other good entry point for developers new to web application development. Nobody wants to (or should have to) read the HTTP spec when they just want a simple CRUD app.
In summary: the reason these JavaScript frameworks exist is 1) Easy starting point for beginners 2) Make web development more like desktop/OOP/whatever the average developer is used to. There there cannot be a "good" web architecture until one is based on how web development actually works, not how we think it should work.
This industry (and most things where many people are involved) is very complex system. There are several different motivations and goals at stake at the same time. I don't know if it is even possible to tell single direction of this system.
I studied industrial automation and I see it as a automation system a bit. To make it simple I compare it to i.e. temperature control. There are many things influencing temperature in a room. Yet we want certain temperature in this room. We try to maintain good temperature and "good" can have multiple meanings. But everything in environment changes constantly and even if nothing changes we still have inertia.
That illustration probably is not that helpful. What I try to say is that it is probably almost impossible to tell where we are heading. We can recognize some general trends for a while, maybe even few longer term. This is very complex system, we see things as we go. In case of this system if we would commonly start to believe that system is heading in certain direction for sure, because of feedback loop it would change this direction.
Maybe what I want to express is just that I think that I should read more on systems and game theory.
I didn't have time to make this post shorter, sorry.
Honestly it's a bit disheartening to see a community with so much insight readily jump to bashing every single "hip new thing" in the browser/JS world, heck, even npm/bower.
I think part of it is because of the proliferation of JS in recent years, whereas many people still have this notion of copy/paste Javascript "skiddies". Even among new grads with significantly less experience, I often hear some voicing concerns that "web developers are not real programmers", or there's "nothing hard about front-end work", "CSS is only for designers", or "only people who can't do CS become web developers".
On the other hand, yes, new frameworks are appearing every day, and it's obvious this is a huge source of frustration; but we do we need to chase every new framework? Is it actually true that an application written in X framework HAS to be re-written every 2 years instead of a pure jQuery-based application? What is preventing you from continuing to use Angular v1, that you have no choice but to port everything to v2? (also worth noting that you can port only parts of your app to v2 and run them in tandem but I digress)
I don't want to start another flame war here (which seems to be a common trend these few days), but how many people do you know that has a deep understanding of the costs of DOM reflows and how to mitigate/minimize them? As a full stack developer who has done quite a bit of front-end work the past few years, I can tell you: not many.
Okay, so maybe you say: "For X and Y application that knowledge isn't important." That very well may be the case, but how about those that build richer and more complex interfaces that (maybe) involves thousands or even hundreds of thousands of elements on the page? What then? Has no one ever seen the absolutely abysmal jank and (lack of) performance some JS apps have?
Is it really so horrible that we have to bash and nitpick on every single thing someone makes in the web community? Is it wrong for your kid to come home one day, exclaim "look what I drew today!", and show you a horrific picture of you looking like a gorilla? Or maybe it's okay that a lot of people are very working hard to do away with the hairy pain points we have currently, make it harder for you to shoot yourself in the foot, and maybe introduce some (small) pain points of their own inadvertently? Maybe it's possible that we're not all perfect humans with perfect ideas?
I'll give a quick example of what it's been like for my experience/or the experience of people I've worked with with jQuery/Angular/React.
jQuery:
I want to update this element, okay I'll add a class or id as an identifier and query the DOM. Then I'll change the text in here. Oh but now I want to add another element to this list here (but I haven't cached the selector because I haven't learned that yet), let me query that element, create a new element, then append it.
Angular:
I want to update the text on this element, okay, I'll change it in $scope, or the template directly. I also need to add a list item, okay, let's just .push() the new record in our $scope variable and it'll appear since we already told Angular to iterate on this model.
As for DOM updates? Well, I may or may not know it, but Angular is going to update it for me on the next $digest cycle which happens in intervals or can be triggered manually, after doing a dirty check for $scope/$watch.
React:
Similar to my thought process with Angular, I update the list item in our model with setState, and React will do its virtual DOM diffs and update for me, or maybe it doesn't update because shouldComponentUpdate told it not to. And it only touches the elements necessary on the actual DOM.
Perhaps it doesn't seem like a big difference, but after working with all 3, speaking from personal experience: once you have to return to doing pure jQuery, you realize how forced and unnatural everything now feels.
A lot of js devs came straight to js without any previous language experience. Hence we are seeing lots of ideas and frameworks thrown out there. The worst example is the proliferation of single function libraries, yes, create a js lib for a single function.
It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run.
I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them.
I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything)
Installing that small, well tested, and standards compliant function using a single npm command is significantly better than trying to do it correctly myself (which would most likely take an hour or so just to look over it's exact functional requirements, and it would most likely have subtle bugs), half-ass it and write my own "not quite reduce but close-ish" that i now need to use everywhere and need to train new hires on because "I didn't want to install a 31 line lib, so now you have this non-standard system that's buggy in it's own strange ways", or copy-and-paste the code from somewhere muddying the legal status of my codebase.
It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language.
Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the churn-rate means that virtually no one will have the exact version of a library that you require pre-cached in their browser.
There's nothing wrong with "going down the bundling path". Virtually every compiled language does this via a linker. Java's jars are another example. You have at least 3-4 different tools for doing this in Python.
In short: "bundling" is just JS catching up to how software was deployed for ages. Source maps are equivalent to leaving debugging symbols in the binary, only without performance costs.
I think part of this is the built in functions/frameworks for Javascript are so small.
Coding in Ruby, C# or whatever is about learning the standard library as much as the syntax.
So much of the churn is caused by the constant rewriting of basic functionality (e.g. date handling), if we had a bigger and standardised standard library, we wouldn't need half of the packages
But no, I never get to read that, just complaints about how the whole community is dumb. Really? That seems unlikely. I don't believe this is pointless tech churn, akin to fashion. It really feels to me, at least, that there is a direction that the tooling is heading. I'm not sure what it is, but I feel like if that's where these conversations were focused (instead of just rejecting the current state of things) we could figure it out.
Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.