4 ms·

This is not a React alternative. It achieves the same end result as React, it's smaller, and it's probably faster in some situations. But those are things that

This is not a React alternative. It achieves the same end result as React, it's smaller, and it's probably faster in some situations. But those are things that pretty much every app shouldn't need to care much about - every framework is fast enough to nail 60fps if you're using it properly, and few of them are so bloated that they add more than a couple of percentage points to the page weight. 3KB is definitely better than 30KB, but if your main bundle is 3000KB your users aren't going to be impressed when you switch. Clearly this varies with the audience you cater for too - a B2B app with 500 users can afford to add a bit more weight to a page than a B2C app with 200,000,000 users. We need to choose our tech accordingly. What most JS developers should really care about is the ecosystem, the tooling, the documentation, the code quality, and the testability of their chosen framework. React really shines here. There's a ton of good libraries, there are some superb tools, the docs are very well written (especially the new beta docs), React's core code is accessible and readable, and (mostly thanks to Kent Dodds) React apps are very testable. A React-based app can be (but too often isn't) written well, be mostly bug free, be fast, and be easy to build a business on. This is why Espresso.js isn't an alternative to React. A dev using it just won't be as capable as a dev using React, because the surrounding tooling isn't there. React isn't just the code that gets bundled in. It's everything else as well. Libraries that claim to be smaller and faster but that lack that quality of dev experience should really concentrate on improving that rather than shaving another 1ms or 0.1KB off the load time.

toastercat 4y ago
This is a weird comment and makes a lot of assumptions on why someone would even choose a view library like this to begin with. React is just React; a small virtual dom library with little opinions on how you test and structure your application. Of course, React has the largest and most mature ecosystem of any modern JavaScript view library, which is what you are getting at.
- enlyth 4y ago
  I think the comment is actually completely on-point and tells that OP isn't just some random backend developer that rants about frontend development. If you're using something in a professional manner, you need to leverage the existing tooling, ecosystem and libraries. Do you have time to rewrite things from scratch like react-testing-library, styled-components, Apollo GraphQL, DraftJS, react-hook-form, and various component libraries? If you want to actually focus on your business logic you don't have time to do this stuff, otherwise you'll spend two weeks making a dropdown.
  - deleted 4y ago
    [deleted]
  - toastercat 4y ago
    I disagree, to me it seems like they are having an argument by themselves simply because the post dare call a minimal view library a "React alternative". EDIT: It's also just kind of off-topic and representative of stereotypical HN cynicism. Also "using something in professional manner" itself is a huge assumption -- are we going to forget that people do front-end development in non-corporate or professional settings? Calling a minimal view library a "React alternative" may be borderline offensive to professional React developers, but it's also actually helpful to people who are looking for an alternative when React doesn't fit their use-case.
    - scrollaway 4y ago
      Espresso.js is a React alternative like TempleOS is a Windows alternative. The ecosystem is a core part of React, because of course it is. It's similar to how people build "wordpress alternatives" that are just a blog with zero plugin capability and then wonder how their better product isn't getting traction. Sure, technically, wordpress is just a blog; but that is not why people choose it. (And I have no love for it)
      - toastercat 4y ago
        I prefer to compare apples to apples. Maybe a better example would be comparing [less popular view library] to React is like comparing Linux w/ Proton to Windows for the purpose of gaming.
    - onion2k 4y ago
      It's also just kind of off-topic and representative of stereotypical HN cynicism. I don't think that's the tone I was aiming for. My point is really that for Espresso, or any other library that's aiming to be an alternative to another big and popular library, needs to do more than just being technically better. It needs good examples, clear docs, support from the community, and ultimately a well thought out "ethos". Espresso is lacking a few of those things. That's not even really a criticism of the library; it's just the state of library development and populism in the JS ecosystem in general. A large part of a devs decision making process comes down to things that aren't code. It's a bit like the "build it, they will come" route to market that kills so many startups. Just making something great isn't enough. You also need to handhold your users to get them to try it.
soulofmischief 4y ago
- scrollaway 4y ago
  "Benefiting from the largest ecosystem in the javascript space" is not a "contrived" reason, what the hell?
  - soulofmischief 4y ago
    Contrived in that OP focused on particular developer needs and ignored the rest. > What most JS developers should really care about is the ecosystem, the tooling, the documentation, the code quality, and the testability of their chosen framework This isn't just OP's opinion. OP is lite gatekeeping by suggesting that most JS developers should share their opinion. I will agree that testability is paramount, but lacking specific contexts (embedded, high-perf, security, etc) the rest of the heuristic deals with a series of trade-offs. OP has possibly worked in a limited context when writing front-end code, and has not been forced to make trade-offs. The most glaring issue with their argument is that developers should stick with libraries that have large ecosystems and tooling. This is an anti-progress, anti-innovation sentiment which does not even hold up. Like another poster said, there was no reason to ever drop jQuery and move to view libraries if ecosystem and tooling were paramount.
lhorie 4y ago
To play devil's advocate for a bit, what you said applies to jQuery as well. It has an enormous plugin ecosystem. I know, I know, people are going to now start pointing out how X or Y specific thing is "better" in React, but then isn't bundle size, application space code conciseness, etc also W and Z specific things? At what point is the argument for one toolchain over another simply circular reasoning / backpatting? Trade-off analysis isn't just pointing at X, it's about looking at the balance of X and Y vs W and Z.
- bobthepanda 4y ago
  jQuery is a bit of an interesting case, because it was so successful that it APIs got implemented in browsers themselves. The advice that I’ve seen is that you should replace jQuery selector stuff with vanilla js and css whenever possible, and for a lot of projects that doesn't leave much.
  - Semaphor 4y ago
    For me that usually ends when a plugin is only available for jQuery.
  - tambourine_man 4y ago
    >jQuery is a bit of an interesting case, because it was so successful that it APIs got implemented in browsers themselves I wish everyday that this was true. It's far from it, unfortunately.
  - derimagia 4y ago
    In the past I recommended people to look at https://github.com/camsong/You-Dont-Need-jQuery https://github.com/camsong/You-Dont-Need-jQuery. I haven't looked at it in a while but it looks up to date.
satvikpendem 4y ago
Indeed, which is why I use React even though new frameworks are popping up; the network effect of the ecosystem is just too strong. I originally learned VueJS but had to abandon it because the libraries I wanted to use just weren't there or were very sparsely supported. Also, I like hooks.
akrymski 4y ago
It was 10 years ago, as was Backbone and many others. IMHO X is an alternative to React if you can build a web app with X. Sometimes less is more. Some people prefer vanilla JS or a lightweight library to a huge framework with an "ecosystem" of baggage.
- MuffinFlavored 4y ago
  As somebody who has done some very gross things with jQuery/vanilla JS when I should've really been using the pattern of "components just redraw themselves based on props/state" (or whatever it is that Reacts boils down to), I'm not so sure this is the right answer. Vanilla JavaScript/jQuery projects probably start off small/without bad intentions. It's what happens to them overtime as they grow (fall apart) in my opinion.

toastercat 4y ago

This is a weird comment and makes a lot of assumptions on why someone would even choose a view library like this to begin with. React is just React; a small virtual dom library with little opinions on how you test and structure your application. Of course, React has the largest and most mature ecosystem of any modern JavaScript view library, which is what you are getting at.

enlyth 4y ago
I think the comment is actually completely on-point and tells that OP isn't just some random backend developer that rants about frontend development. If you're using something in a professional manner, you need to leverage the existing tooling, ecosystem and libraries. Do you have time to rewrite things from scratch like react-testing-library, styled-components, Apollo GraphQL, DraftJS, react-hook-form, and various component libraries? If you want to actually focus on your business logic you don't have time to do this stuff, otherwise you'll spend two weeks making a dropdown.
- deleted 4y ago
  [deleted]
- toastercat 4y ago
  I disagree, to me it seems like they are having an argument by themselves simply because the post dare call a minimal view library a "React alternative". EDIT: It's also just kind of off-topic and representative of stereotypical HN cynicism. Also "using something in professional manner" itself is a huge assumption -- are we going to forget that people do front-end development in non-corporate or professional settings? Calling a minimal view library a "React alternative" may be borderline offensive to professional React developers, but it's also actually helpful to people who are looking for an alternative when React doesn't fit their use-case.
  - scrollaway 4y ago
    Espresso.js is a React alternative like TempleOS is a Windows alternative. The ecosystem is a core part of React, because of course it is. It's similar to how people build "wordpress alternatives" that are just a blog with zero plugin capability and then wonder how their better product isn't getting traction. Sure, technically, wordpress is just a blog; but that is not why people choose it. (And I have no love for it)
    - toastercat 4y ago
      I prefer to compare apples to apples. Maybe a better example would be comparing [less popular view library] to React is like comparing Linux w/ Proton to Windows for the purpose of gaming.
  - onion2k 4y ago
    It's also just kind of off-topic and representative of stereotypical HN cynicism. I don't think that's the tone I was aiming for. My point is really that for Espresso, or any other library that's aiming to be an alternative to another big and popular library, needs to do more than just being technically better. It needs good examples, clear docs, support from the community, and ultimately a well thought out "ethos". Espresso is lacking a few of those things. That's not even really a criticism of the library; it's just the state of library development and populism in the JS ecosystem in general. A large part of a devs decision making process comes down to things that aren't code. It's a bit like the "build it, they will come" route to market that kills so many startups. Just making something great isn't enough. You also need to handhold your users to get them to try it.

soulofmischief 4y ago

scrollaway 4y ago
"Benefiting from the largest ecosystem in the javascript space" is not a "contrived" reason, what the hell?
- soulofmischief 4y ago
  Contrived in that OP focused on particular developer needs and ignored the rest. > What most JS developers should really care about is the ecosystem, the tooling, the documentation, the code quality, and the testability of their chosen framework This isn't just OP's opinion. OP is lite gatekeeping by suggesting that most JS developers should share their opinion. I will agree that testability is paramount, but lacking specific contexts (embedded, high-perf, security, etc) the rest of the heuristic deals with a series of trade-offs. OP has possibly worked in a limited context when writing front-end code, and has not been forced to make trade-offs. The most glaring issue with their argument is that developers should stick with libraries that have large ecosystems and tooling. This is an anti-progress, anti-innovation sentiment which does not even hold up. Like another poster said, there was no reason to ever drop jQuery and move to view libraries if ecosystem and tooling were paramount.

lhorie 4y ago

To play devil's advocate for a bit, what you said applies to jQuery as well. It has an enormous plugin ecosystem. I know, I know, people are going to now start pointing out how X or Y specific thing is "better" in React, but then isn't bundle size, application space code conciseness, etc also W and Z specific things? At what point is the argument for one toolchain over another simply circular reasoning / backpatting? Trade-off analysis isn't just pointing at X, it's about looking at the balance of X and Y vs W and Z.

bobthepanda 4y ago
jQuery is a bit of an interesting case, because it was so successful that it APIs got implemented in browsers themselves. The advice that I’ve seen is that you should replace jQuery selector stuff with vanilla js and css whenever possible, and for a lot of projects that doesn't leave much.
- Semaphor 4y ago
  For me that usually ends when a plugin is only available for jQuery.
- tambourine_man 4y ago
  >jQuery is a bit of an interesting case, because it was so successful that it APIs got implemented in browsers themselves I wish everyday that this was true. It's far from it, unfortunately.
- derimagia 4y ago
  In the past I recommended people to look at https://github.com/camsong/You-Dont-Need-jQuery https://github.com/camsong/You-Dont-Need-jQuery. I haven't looked at it in a while but it looks up to date.

satvikpendem 4y ago

Indeed, which is why I use React even though new frameworks are popping up; the network effect of the ecosystem is just too strong. I originally learned VueJS but had to abandon it because the libraries I wanted to use just weren't there or were very sparsely supported. Also, I like hooks.

akrymski 4y ago

It was 10 years ago, as was Backbone and many others. IMHO X is an alternative to React if you can build a web app with X. Sometimes less is more. Some people prefer vanilla JS or a lightweight library to a huge framework with an "ecosystem" of baggage.

MuffinFlavored 4y ago
As somebody who has done some very gross things with jQuery/vanilla JS when I should've really been using the pattern of "components just redraw themselves based on props/state" (or whatever it is that Reacts boils down to), I'm not so sure this is the right answer. Vanilla JavaScript/jQuery projects probably start off small/without bad intentions. It's what happens to them overtime as they grow (fall apart) in my opinion.