Hacker News Reader

Comment by rhengles | Hacker News Reader

I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0]

It is the simplest thing I could conceive (to build, not to use - I plan to provide more convenience, but the selling point is the ability to customize everything.) It's template based and without a virtual dom - during render, each variable used will be listened and when it changes, the element that uses it is updated directly, without recomparing the whole tree. It's still in progress.

[0] https://github.com/arijs/ari

View on HN

Have you tried React? It feels fairly library-esque to me. You can be useful in as little as two lines of code:

const elem = React.createElement('div', null, 'Hello World');

ReactDOM.render(elem, document.querySelector('body'));

It's 35.9kB gzipped, although "too big" is subjective. I may be unimaginative, but over my last 5 years or so with it, there isn't much I've wanted to change. As a library consumer, I don't personally mind if a VDOM is used or not, so long as performance is good enough not to ship a noticeably lagging UI to my users. Having experienced both React and Angular --one uses VDOM, the other not-- I haven't found this implementation detail to meaningfully impact performance, but I spent my time building straightforward CRUD apps.

I would consider sharing an example to Ari of something that's hard to do in React/Vue/Angular, and how it's made simple with AriJS. That might help elucidate where it shines, and the key problem being solved.

Thank you! Yes, i've tried it. You can think of me like someone that prefers an old model of the Porsche 911 than the latest model - too much technology that you can't fix yourself, and that's my primary concern with the major frameworks - they're not simple to reimplement!

> Have you tried React? It feels fairly library-esque to me.

Because it is, in fact, just a library.

React implements the component lifecycle, calling into the component to do it, stores all the component state, and reconciles DOM changes on behalf of the component. It's the very definition of a framework - it's calls the component, the component doesn't call it.

It has been said it is a library, but imo it is not for the reason how it forces you to write code according to their rules. For instance functional components. Most of the code you write is to fit React, so for this reason I would say it is a framework.

Off the cuff, that sounds a lot like Knockout.

https://knockoutjs.com/

Knockout was the last time I felt I really understood the js ecosystem. Since then it’s a mess of npm, webpack, and long complicated front end builds to do simple things.

What interesting is of all the js code I’ve written the code that lasted the longest was pure business logic Written in vanilla js, separated from any library or framework. It’s gone through knockout, angular, and react versions of the site, and people always try to rewrite it the new way, but it just doesn’t work as well and they end up writing a thin simple shim to bridge the old and new code.

You can use React like a library. You can even go without JSX, though nobody really does. React is also kind of odd because it includes a bunch of other stuff like hooks, even though most people bring their own state management to it. But it's definitely the least-framework-y of all the major frameworks.

I understand where you're coming from - it is advertised as the 'view layer'. But I think that templates are more similar to the native browser language - html, so it is easier to grasp. It is also simpler and easier to implement than a js+jsx parser.

Nobody does react without jsx because it is the worst of both worlds, but if React had template strings (not necessarily built-in but at least as a first-party plugin) it would be a more viable option.

React by itself is just a templating language, yeah I got it.

But i think for most devs out there, like 99% (yeah I made this up) of them, React is actually React + React-dom, the latter per the account of the official team is like a runtime thing, which perfectly fits into the description of a framework.

For years I used react without jsx - with a few minor conventions to make it shorter to write elements via JS (`_div(...)` being equivalent to the jsx `<div>{...}</div>`, and some minor variant for elems with attrs) it's quite easy to build trees using plain old JS syntax.

The advantages of doing that were better tooling support, since everything under the sun supported JS, but not necessarily JSX very well, and jsx isn't really all that important anyhow. Obviously that's not a factor anymore today ;-).

Yep! Really the non-JSX syntax is very close to that of most virtual DOM-based rendering libraries, including the fairly popular Mithril.js

Reply on news.ycombinator.com