7 ms·

Just wait. You are going to start adding modules and eventually you're going to have a whole ecosystem. Someone is going to complain about the bloat and then

Just wait. You are going to start adding modules and eventually you're going to have a whole ecosystem. Someone is going to complain about the bloat and then build the new simpler JS framework that's basically your version 1.0. I've seen this movie several times over the last 10 years.

devwastaken 6y ago
It's a fun thing to do that lets you learn the core issues frameworks try to solve. People then post their work because we have to legitimately market ourselves and our work somehow. 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.
- ForHackernews 6y ago
  > People then post their work because we have to legitimately market ourselves and our work somehow. Wouldn't it be better if we experimented with radical new ideas for development instead of reinventing the same JavaScript wheel for 300th time?
  - nailer 6y ago
    Svelte did this by throwing away virtual DOMs and using a compiler to directly bind elements to data.
  - Xevi 6y ago
    We are though. One of the current shift that is happening is that frameworks are moving away from using Webpack and so on during development. Vue now has Vite, Svelte is moving to Snowpack, etc. This can speed up development iteration time by orders of magnitudes.
  - worldsayshi 6y ago
    I agree that that would be swell but sometimes you have to practice the same movements as those that came before to learn something new?
- LandR 6y ago
  > because we have to legitimately market ourselves and our work somehow. Do we ?
  - cy_hauser 6y ago
    If we went to be "better than average" then yes. You must do something to stick out in order to get better jobs, more money, more fame, more power, etc.
  - lhorie 6y ago
    You don't. But I did and now get paid 3 times more than I did before. There aren't enough high paying bay area jobs to go around for all developers in the world, so as they say, early bird gets the worm.
bryanrasmussen 6y ago
A lot of bloat however, is caused by uptake of the frameworks and having to also support older versions etc. As long nobody but you uses it you can add/rewrite as needed while keeping bloat to a minimum.
- Cthulhu_ 6y ago
  Plus things like performance optimizations; people have been building lightweight alternatives to React for years now, the core concept is not that difficult. Making it performant is the one though.
jbergstroem 6y ago
Most of us watches movies all the time, but without the movie makers there’s nothing for the rest of us to review.
zappo2938 6y ago
I'm going to stick with React until web assembly frameworks are common in 5 - 10 years.
prox 6y ago
Is it weird if I still use vanilla JS most of the time? And some jQuery where absolutely needed?
- pstadler 6y ago
  This IS weird, because of the jQuery part.
  - jailbird_bd 6y ago
    Could you please describe why? jQuery is basically just a bunch of helper functions which makes your JS code a bit more readable and takes away the worry about browser (in)compatibility. Is that bad?
    - rendall 6y ago
      No. It's not bad. As with everything in tech, there are: 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"
      - FpUser 6y ago
        >"As for jQuery specifically, there has been at least 2 trends militating against it" 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.
        deleted 6y ago
        [deleted]
otar 6y ago
This!
mhaberl 6y ago
> I've seen this movie several times over the last 10 years. 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..
lucideer 6y ago
I don't understand how this is the top comment. It's so generic and lacks any investigation or insight; I could copypaste this as a reply to any software project post on HN and it could vaguely apply in the same way (but not specifically apply). 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.
- chiefalchemist 6y ago
  > I don't understand how this is the top comment. It's so generic and lacking of any investigation or insight; I could copypaste this as a reply to any software project post on HN and it could vaguely apply in the same way (but not specifically apply). 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.
  - lhorie 6y ago
    > die 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.
defx 6y ago
I've seen that too, but there are also tons of projects that stay true to their original intentions and it wouldn't make sense (to me at least) to morph synergy into a "one size fits all" framework. It has a clear set of responsibilities and my ultimate hope for this library is that it will be eventually become redundant as all of the features it provides become a part of the web platform itself.
lhorie 6y ago
Counterpoint: mithril.js has been feature complete for years, and the culture around it is to resist change for the sake of change (e.g. it didn't jump into the react hooks bandwagon like vue did, even though it's arguably more similar to react than vue is) 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.
- oofoe 6y ago
  Three cheers for mithril.js! I've used it for a number of things, including a complete rewrite of a heavy old app that used Ext.js. It was very simple to set up dynamic page assembly for very fast and flexible UIs. 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...
raj_khare 6y ago
Second law of thermodynamics, sigh
Existenceblinks 6y ago
I do not see this happens with https://github.com/WebReflection/uhtml/blob/master/DOCUMENTATION.md https://github.com/WebReflection/uhtml/blob/master/DOCUMENTA... family. They are around for quite awhile, and their philosophy is clear from start, do one thing well, small and no tooling.
mekkkkkk 6y ago
As long as it's flagged "Show HN", it's all good. You shouldn't be taking it more seriously than it is. I bet you don't have the same response when someone posts some other pet project of bouncing balls in WebGL and WASM Rust or something. 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 .

devwastaken 6y ago

It's a fun thing to do that lets you learn the core issues frameworks try to solve. People then post their work because we have to legitimately market ourselves and our work somehow. 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.

ForHackernews 6y ago
> People then post their work because we have to legitimately market ourselves and our work somehow. Wouldn't it be better if we experimented with radical new ideas for development instead of reinventing the same JavaScript wheel for 300th time?
- nailer 6y ago
  Svelte did this by throwing away virtual DOMs and using a compiler to directly bind elements to data.
- Xevi 6y ago
  We are though. One of the current shift that is happening is that frameworks are moving away from using Webpack and so on during development. Vue now has Vite, Svelte is moving to Snowpack, etc. This can speed up development iteration time by orders of magnitudes.
- worldsayshi 6y ago
  I agree that that would be swell but sometimes you have to practice the same movements as those that came before to learn something new?
LandR 6y ago
> because we have to legitimately market ourselves and our work somehow. Do we ?
- cy_hauser 6y ago
  If we went to be "better than average" then yes. You must do something to stick out in order to get better jobs, more money, more fame, more power, etc.
- lhorie 6y ago
  You don't. But I did and now get paid 3 times more than I did before. There aren't enough high paying bay area jobs to go around for all developers in the world, so as they say, early bird gets the worm.

bryanrasmussen 6y ago

A lot of bloat however, is caused by uptake of the frameworks and having to also support older versions etc. As long nobody but you uses it you can add/rewrite as needed while keeping bloat to a minimum.

Cthulhu_ 6y ago
Plus things like performance optimizations; people have been building lightweight alternatives to React for years now, the core concept is not that difficult. Making it performant is the one though.

jbergstroem 6y ago

Most of us watches movies all the time, but without the movie makers there’s nothing for the rest of us to review.

zappo2938 6y ago

I'm going to stick with React until web assembly frameworks are common in 5 - 10 years.

prox 6y ago

Is it weird if I still use vanilla JS most of the time? And some jQuery where absolutely needed?

pstadler 6y ago
This IS weird, because of the jQuery part.
- jailbird_bd 6y ago
  Could you please describe why? jQuery is basically just a bunch of helper functions which makes your JS code a bit more readable and takes away the worry about browser (in)compatibility. Is that bad?
  - rendall 6y ago
    No. It's not bad. As with everything in tech, there are: 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"
    - FpUser 6y ago
      >"As for jQuery specifically, there has been at least 2 trends militating against it" 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.
      - deleted 6y ago
        [deleted]

otar 6y ago

This!

mhaberl 6y ago

> I've seen this movie several times over the last 10 years. 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..

lucideer 6y ago

I don't understand how this is the top comment. It's so generic and lacks any investigation or insight; I could copypaste this as a reply to any software project post on HN and it could vaguely apply in the same way (but not specifically apply). 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.

chiefalchemist 6y ago
> I don't understand how this is the top comment. It's so generic and lacking of any investigation or insight; I could copypaste this as a reply to any software project post on HN and it could vaguely apply in the same way (but not specifically apply). 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.
- lhorie 6y ago
  > die 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.

defx 6y ago

I've seen that too, but there are also tons of projects that stay true to their original intentions and it wouldn't make sense (to me at least) to morph synergy into a "one size fits all" framework. It has a clear set of responsibilities and my ultimate hope for this library is that it will be eventually become redundant as all of the features it provides become a part of the web platform itself.

lhorie 6y ago

Counterpoint: mithril.js has been feature complete for years, and the culture around it is to resist change for the sake of change (e.g. it didn't jump into the react hooks bandwagon like vue did, even though it's arguably more similar to react than vue is) 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.

oofoe 6y ago
Three cheers for mithril.js! I've used it for a number of things, including a complete rewrite of a heavy old app that used Ext.js. It was very simple to set up dynamic page assembly for very fast and flexible UIs. 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...

raj_khare 6y ago

Second law of thermodynamics, sigh

Existenceblinks 6y ago

I do not see this happens with https://github.com/WebReflection/uhtml/blob/master/DOCUMENTATION.md https://github.com/WebReflection/uhtml/blob/master/DOCUMENTA... family. They are around for quite awhile, and their philosophy is clear from start, do one thing well, small and no tooling.

mekkkkkk 6y ago

As long as it's flagged "Show HN", it's all good. You shouldn't be taking it more seriously than it is. I bet you don't have the same response when someone posts some other pet project of bouncing balls in WebGL and WASM Rust or something. 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 .