26 ms·

Espresso.js – minimal React alternative – is now a decade old

87 points by akrymski 4y ago

ricardobeat 4y ago
The likely reason it never caught on, is that the library has similar pitfalls to Backbone. The entire application and component lifecycle has to be coded explicitly: - manually attaching DOM elements to view controllers - manually attaching child views - models which have to be wired individually via .listenTo - models can be out of sync - possibility of infinite loops if the events accidentally recurse A better tiny alternative would be hyperapp[1] or even Preact, that has a similar bundle size. [1] https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp
- bluefirebrand 4y ago
  This was a lot of the problems I had when I had to work with KnockoutJS as well. So much boilerplate, I could spend a whole day writing code and barely have the same stuff written that it would take me two hours to do with React. I love stuff that makes me more productive and minimizes my boilerplate writing.
  - ricardobeat 4y ago
    Modern React code with hooks, contexts and all went almost full circle though, it's now not too far off from the amount of code you'd write with Backbone, maybe more.
    - woah 4y ago
      You don't have to use any of that stuff. You can still have React act as a glorified template library, drill all your data down through props, etc.
    - bobthepanda 4y ago
      Hooks, by themselves, can be ok, since you avoid componentDidMount, componentDidUnmount, etc. I’ve started enjoying functional components more once I realized I could destructure props in the function parameters rather than in the very first line of the method.
  - b4je7d7wb 4y ago
    I hate the boilerplate in react. Import, types for props, exports and all the hooks. Many codebases I've seen have even conventions which increase it. Small things but it adds up and I unconciously avoid creating new components when possible. Many people use some shortcuts to autogenerate all of this stuff, but I don't like tools like this. Svelte is the gold standard of no boilerplate. An empty file is a valid component.
- akrymski 4y ago
  I don't believe any of those apply to this library. But indeed those were the issues with Backbone at the time. Check out an example app: https://github.com/akrymski/espresso.js/tree/master/examples/todomvc https://github.com/akrymski/espresso.js/tree/master/examples...
  - ricardobeat 4y ago
    The infinite loop for example, is easy to get with a circular chain: 'change' -> .listenTo subscriber -> triggers another change. Probably won't happen in a single file, but because updates can come from anywhere, as an app grows you are exponentially more likely to accidentally get one. The example demonstrates a couple of the downsides, like directly wiring listenTo -> render, but it has no child views or interaction between different models / collections. With a bit more complexity I'm sure it would hit all of those points. Did you ever end up building a production app with the library?
    - akrymski 4y ago
      Yes I've written several apps with it. It does have child views (to do item). You can't get a circular chain any more than with react. ListenTo is written manually only for special cases there, otherwise a controller is simply bound to a model and it's all handled for you.
sesm 4y ago
Another ‘React before React’ is webfui from ClojureScript world: https://github.com/drcode/webfui https://github.com/drcode/webfui When React was first released, general JS public was skeptical towards it, but ClojureScript community immediately embraced it. One of the early articles praising React for it’s performance was written by David Nolen: https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ https://swannodette.github.io/2013/12/17/the-future-of-javas...
thunkle 4y ago
You can tell it's old because it is some derivative of "java".
- knoebber 4y ago
  I wonder how many folks chose Expresso.js + coffee script because it was the 'hot new thing'.
  - ironmagma 4y ago
    "Hot new thing" is overstated as a reason people pick up tech. You could as accurately imagine it as "scary new thing."
- throwaway4good 4y ago
  Coffee references are not going to disappear from the computing world anytime soon.
deleted 4y ago
[deleted]
hombre_fatal 4y ago
Something I notice when dabbling in random client side frameworks is how it’s not obvious how to go from the building blocks in the docs to more complex use cases. SwiftUI is a great example of this struggle where the docs show API building blocks but tend to end before getting across the sort of higher level understanding that lets you synthesize less-trivial patterns on your own. The Combine docs (SwiftUI’s reactive/observable abstraction) will go on and on but never explain that this is the tool you are supposed to use for, say, computed properties, so most people will try to create more @State constructs that get updated in a didUpdate block or come up with some other solution. It’s something that’s easy to take for granted when using React where the docs try to give you at least a raging clue about intended use cases and are considered failures if they don’t, and it’s popularity means at least many have asked the same questions before you. It’s a major point we dismiss when we complain about people “cargo culting” popular tech, especially in the UI space where the Best Solution remains an open question and the subject of continual experimentation.
- mephos 4y ago
  Broadly speaking, I think this is one area where people struggle when getting started with programming. You can read the docs about given library function but often it's not clear how that certain function should be used in practice, leading to confusion and ultimately Stack Overflow.
- jrumbut 4y ago
  This is painfully true in every area. I wish documentation writers would focus less on exhaustively documenting every single thing and instead really explain the surprising parts. Maybe don't even worry about documenting the "height" parameter. I'll figure out if it's in pixels or percent or rems soon enough. But if you have a parameter called "snefbolian" I really want a paragraph or more explaining that, it isn't sufficient to give the unit.
  - iudqnolq 4y ago
    "Why are you giving me a pixel? In this context we switch to a unit defined as 1/72 of an inch on a screen with standard pixel density." - Poppler (Yes, I know it's because they're using printer vocabulary for rendering. I know this because I googled the magic numbers in their example code. It would have been nice to read something on the docs)
onion2k 4y ago
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.
revskill 4y ago
I use React.js because no need to use `extend` from OOP.
ilrwbwrkhv 4y ago
Imba.io blows all of this completely out of the water.
- deleted 4y ago
  [deleted]
insane_dreamer 4y ago
Is Espresso to React what Flask is to Django, or Sinatra to Rails? I haven't used React, but I far prefer Flask to Django; in many cases you don't need all that extra overhead and complexity that the "full-featured" framework provides.
- salt-thrower 4y ago
  I wouldn’t compare React to Django and Rails, as in being a “full framework” that is opinionated and has specific ways of doing things. React is still more of just a rendering library than a framework in the traditional sense.
akrymski 4y ago
Few interesting ideas: - Clear separation between HTML markup and code, the DOM is static and is not generated by createElement(..) - No virtual DOM or HTML diffing: every component has an internal state and updates the corresponding DOM attributes as needed TO DO example: https://github.com/akrymski/espresso.js/tree/master/examples/todomvc https://github.com/akrymski/espresso.js/tree/master/examples...
pkrumins 4y ago
HTML tag - minimal React alternative - is now three decades old.

87 points by akrymski 4y ago

The likely reason it never caught on, is that the library has similar pitfalls to Backbone. The entire application and component lifecycle has to be coded explicitly: - manually attaching DOM elements to view controllers - manually attaching child views - models which have to be wired individually via .listenTo - models can be out of sync - possibility of infinite loops if the events accidentally recurse A better tiny alternative would be hyperapp[1] or even Preact, that has a similar bundle size. [1] https://github.com/jorgebucaran/hyperapp https://github.com/jorgebucaran/hyperapp

bluefirebrand 4y ago
This was a lot of the problems I had when I had to work with KnockoutJS as well. So much boilerplate, I could spend a whole day writing code and barely have the same stuff written that it would take me two hours to do with React. I love stuff that makes me more productive and minimizes my boilerplate writing.
- ricardobeat 4y ago
  Modern React code with hooks, contexts and all went almost full circle though, it's now not too far off from the amount of code you'd write with Backbone, maybe more.
  - woah 4y ago
    You don't have to use any of that stuff. You can still have React act as a glorified template library, drill all your data down through props, etc.
  - bobthepanda 4y ago
    Hooks, by themselves, can be ok, since you avoid componentDidMount, componentDidUnmount, etc. I’ve started enjoying functional components more once I realized I could destructure props in the function parameters rather than in the very first line of the method.
- b4je7d7wb 4y ago
  I hate the boilerplate in react. Import, types for props, exports and all the hooks. Many codebases I've seen have even conventions which increase it. Small things but it adds up and I unconciously avoid creating new components when possible. Many people use some shortcuts to autogenerate all of this stuff, but I don't like tools like this. Svelte is the gold standard of no boilerplate. An empty file is a valid component.
akrymski 4y ago
I don't believe any of those apply to this library. But indeed those were the issues with Backbone at the time. Check out an example app: https://github.com/akrymski/espresso.js/tree/master/examples/todomvc https://github.com/akrymski/espresso.js/tree/master/examples...
- ricardobeat 4y ago
  The infinite loop for example, is easy to get with a circular chain: 'change' -> .listenTo subscriber -> triggers another change. Probably won't happen in a single file, but because updates can come from anywhere, as an app grows you are exponentially more likely to accidentally get one. The example demonstrates a couple of the downsides, like directly wiring listenTo -> render, but it has no child views or interaction between different models / collections. With a bit more complexity I'm sure it would hit all of those points. Did you ever end up building a production app with the library?
  - akrymski 4y ago
    Yes I've written several apps with it. It does have child views (to do item). You can't get a circular chain any more than with react. ListenTo is written manually only for special cases there, otherwise a controller is simply bound to a model and it's all handled for you.

sesm 4y ago

Another ‘React before React’ is webfui from ClojureScript world: https://github.com/drcode/webfui https://github.com/drcode/webfui When React was first released, general JS public was skeptical towards it, but ClojureScript community immediately embraced it. One of the early articles praising React for it’s performance was written by David Nolen: https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ https://swannodette.github.io/2013/12/17/the-future-of-javas...

thunkle 4y ago

You can tell it's old because it is some derivative of "java".

knoebber 4y ago
I wonder how many folks chose Expresso.js + coffee script because it was the 'hot new thing'.
- ironmagma 4y ago
  "Hot new thing" is overstated as a reason people pick up tech. You could as accurately imagine it as "scary new thing."
throwaway4good 4y ago
Coffee references are not going to disappear from the computing world anytime soon.

deleted 4y ago

[deleted]

hombre_fatal 4y ago

Something I notice when dabbling in random client side frameworks is how it’s not obvious how to go from the building blocks in the docs to more complex use cases. SwiftUI is a great example of this struggle where the docs show API building blocks but tend to end before getting across the sort of higher level understanding that lets you synthesize less-trivial patterns on your own. The Combine docs (SwiftUI’s reactive/observable abstraction) will go on and on but never explain that this is the tool you are supposed to use for, say, computed properties, so most people will try to create more @State constructs that get updated in a didUpdate block or come up with some other solution. It’s something that’s easy to take for granted when using React where the docs try to give you at least a raging clue about intended use cases and are considered failures if they don’t, and it’s popularity means at least many have asked the same questions before you. It’s a major point we dismiss when we complain about people “cargo culting” popular tech, especially in the UI space where the Best Solution remains an open question and the subject of continual experimentation.

mephos 4y ago
Broadly speaking, I think this is one area where people struggle when getting started with programming. You can read the docs about given library function but often it's not clear how that certain function should be used in practice, leading to confusion and ultimately Stack Overflow.
jrumbut 4y ago
This is painfully true in every area. I wish documentation writers would focus less on exhaustively documenting every single thing and instead really explain the surprising parts. Maybe don't even worry about documenting the "height" parameter. I'll figure out if it's in pixels or percent or rems soon enough. But if you have a parameter called "snefbolian" I really want a paragraph or more explaining that, it isn't sufficient to give the unit.
- iudqnolq 4y ago
  "Why are you giving me a pixel? In this context we switch to a unit defined as 1/72 of an inch on a screen with standard pixel density." - Poppler (Yes, I know it's because they're using printer vocabulary for rendering. I know this because I googled the magic numbers in their example code. It would have been nice to read something on the docs)

onion2k 4y ago

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.

revskill 4y ago

I use React.js because no need to use `extend` from OOP.

ilrwbwrkhv 4y ago

Imba.io blows all of this completely out of the water.

deleted 4y ago
[deleted]

insane_dreamer 4y ago

Is Espresso to React what Flask is to Django, or Sinatra to Rails? I haven't used React, but I far prefer Flask to Django; in many cases you don't need all that extra overhead and complexity that the "full-featured" framework provides.

salt-thrower 4y ago
I wouldn’t compare React to Django and Rails, as in being a “full framework” that is opinionated and has specific ways of doing things. React is still more of just a rendering library than a framework in the traditional sense.

akrymski 4y ago

Few interesting ideas: - Clear separation between HTML markup and code, the DOM is static and is not generated by createElement(..) - No virtual DOM or HTML diffing: every component has an internal state and updates the corresponding DOM attributes as needed TO DO example: https://github.com/akrymski/espresso.js/tree/master/examples/todomvc https://github.com/akrymski/espresso.js/tree/master/examples...

pkrumins 4y ago

HTML tag - minimal React alternative - is now three decades old.