Case in point with JS libs and the following line: "You are going to start adding modules and eventually you're going to have a whole ecosystem". This happens with individual JS-built products using libs, but definitely does not happen universally with most JS libraries. Take React, the first comparator referenced in the post title: its ecosystem is entirely 3rd-party addons and the core is focused and single-purpose to this day. They've added a lot of internal complexity to their vdom implementation which adds code bloat, but it isn't what this commenter is describing.
Vague comments like this never apply to all cases (often apply to no cases). It's a lazy comment that contributes nothing without being specific to this new library. You need to read the code and develop some genuine insight to have this type of commentary.
Yes. And that is _exactly_ the point. These anti-bloat libraries either die or become the enemy they set out to defeat. We've been to this rodeo before, yes?
Nothing wrong with that per se. But we gain nothing by pretending this cycle doesn't exist.
Perhaps a smarter approach would be: I've replicated 80% of X's features with 20% of the weight. Here's what's missing.
Then if Library X puts on weight, so can you, if you want. But feather weight in and of itself is not a benefit per se (especially when it's likely temporary). It's a feature. And too often we all gets sucked into the feature trap because we forget it's ultimately about benefits.
This probably isn't true, but more importantly this statement misses the point because you're bundling a bunch of stuff into the "anti-bloat libs" bucket with no consideration for the individual architectures of each.
To come back to the example above—React—the core react library is 3.2kb[0] gzipped. (and it hasn't died out). What I'm selectively omitting here is the architectural detail that React have separated their API implementation (core), their renderers (DOM, Server, Native) and their templating (JSX), all of which are loosely coupled optional components. That's a very effective approach to omitting bloat, and is a model that can be copied in an approximately compatible way (see e.g. the anti-bloat Preact and Inferno, further examples of anti-bloat approaches that have not "died out")
[0] https://unpkg.com/[email protected]/cjs/react.production.min.js
This idea puzzles me. It's not like the code suddenly breaks or the world changes so much as to render it completely obsolete.
It's borderline madness to keep chasing new and shiny things and then complain that things keep changing.
Stability is a feature, not a bug.
To be Clear; The submitted ShowHN is a welcome effort and espouses (imo) fantastic ideals and objectives. I'm glad that people like the developer take/make the time to contribute to the greater good of the open source community.
It is also great/fantastic/good/{some other positive superlative} that people like the submitter keep on fighting the good fight when it comes to program bloat.
While I'm not trying to read another persons thoughts here - Perhaps their comment was indeed meant as a 'oh another thing that's gonna end up bloated due to feature request creep' (which was my initial jaded reaction too although I just didn't think it was an opinion worthwhile posting as a comment that contributed something worthwhile to the conversation so didn't do so).
Call it a measure of the current global mood within the HN that the comment became the top voted comment.
As to what my point was? Uhmmm I forget.
There's lots of avenues that can be taken with things similar to react - and trying and experimenting can create some better methods. It's not as if react or vue were built in isolation from all the previous software.
Do we ?
Wouldn't it be better if we experimented with radical new ideas for development instead of reinventing the same JavaScript wheel for 300th time?
Ecosystem-wise, it encourages integrating with high quality vanilla libraries directly instead of having a react-this or vue-that for everything under the sun.
This approach has worked well, IMHO.
I've tried mentioning it to friends in web dev, but they don't seem to be willing -- if they even look at it, they never try it out. At this point, I just shrug and go back to my simple, reliable and fast pages which load in KB instead of MB...
Not sure what particular insights. Well here is some example: state management. It is basically split into 2 parts. One part is the actual business object that matters and is a slice of full data on backend. It is a class with methods that take parameters and modify state when executed and broadcasting fact of said modifications so that the UI is aware. Executions of said methods also causing data exchange with the backend using JSON based RPC. Simple example would be Customer with get/set Name/Alias/DOB etc.
Then there are web components and those keep their own state that is limited strictly to presentation issue. For example Currently active form of the application.
It is a big area in general with lots of details and requires way more than a simple post to describe. Unfortunately we do not contribute to open source so can't really share any code.
So structurally the app is fairly simple. Some JavaScript files that are being merged when posting to production and backend server written in C++ accessible through JSON based RPC that can serve thousands of requests per second on single computer with few real cores without breaking much sweat.
1) tradeoffs, preferences, exigencies of use-case
2) devs who conflate their specific use-cases with universal truths
3) fickle winds of fashion affects tech as much as any human endeavor. Right now jQuery is out and React is in
As for jQuery specifically, there has been at least 2 trends militating against it: a wider industry move away from patterns of direct DOM manipulation into virtual DOMs (i.e. using frontend frameworks); and a more widespread acceptance of functional programming techniques while jQuery is inherently "impure"
Using virtual DOM does not give much benefit if at all on modern browsers.
Functional programming is just one of many existing paradigms and not a silver bullet. One does not need to plug every hole with it.
I would note in passing that a description of industry trends is not an endorsement of them. There are lots of reasons for trends beyond pure rational technical strategy.
As for developer pool - when I need to hire subcontractor I've never had problems finding one with enough qualifications in whatever area I would need. Btw all subcontractors I've ever had are remote since year 2000
I've been working as a frontend developer most of my life, so I see what you're saying. Still, it's a just a fun thing to do. I've made some hobby libraries myself with no intention of it "catching on". And even if it's reinventing the wheel, perhaps one of the spokes is improved .
As long nobody but you uses it you can add/rewrite as needed while keeping bloat to a minimum.
When you take into consideration other languages and their ecosystems this was happening from the start. It is just evolution. If this lib gets enough traction and goes into the right direction, whatever that may be, it will become popular. Ofcourse chances are small, but..