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.<p>What most JS developers should <i>really</i> 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.<p>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 <i>just</i> 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 <i>that</i> rather than shaving another 1ms or 0.1KB off the load time.
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.<p>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.<p>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.<p>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.<p>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.
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:<p>- manually attaching DOM elements to view controllers<p>- manually attaching child views<p>- models which have to be wired individually via .listenTo<p>- models can be out of sync<p>- possibility of infinite loops if the events accidentally recurse<p>A better tiny alternative would be hyperapp[1] or even Preact, that has a similar bundle size.<p>[1] <a href="https://github.com/jorgebucaran/hyperapp" rel="nofollow">https://github.com/jorgebucaran/hyperapp</a>
Another ‘React before React’ is webfui from ClojureScript world: <a href="https://github.com/drcode/webfui" rel="nofollow">https://github.com/drcode/webfui</a><p>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: <a href="https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/" rel="nofollow">https://swannodette.github.io/2013/12/17/the-future-of-javas...</a>
Few interesting ideas:<p>- Clear separation between HTML markup and code, the DOM is static and is not generated by createElement(..)<p>- No virtual DOM or HTML diffing: every component has an internal state and updates the corresponding DOM attributes as needed<p>TO DO example: <a href="https://github.com/akrymski/espresso.js/tree/master/examples/todomvc" rel="nofollow">https://github.com/akrymski/espresso.js/tree/master/examples...</a>
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.