4 ms·
I like it. I doubt I'd go back to a framework where the user's code is responsible for managing the DOM though. I feel like with this you either end up with a b
by BigJono 5y ago
I like it. I doubt I'd go back to a framework where the user's code is responsible for managing the DOM though. I feel like with this you either end up with a bit of "clear and repopulate" boilerplate for each component, or you build half of React yourself (state and automatic rerendering). It feels more like half of a solution to a single problem rather than complete solutions to a smaller number of problems (relative to React).
I'd probably compare this to something like Preact, which is relatively lean. The React API has always been very simple already. It's just all the other stuff people use with it that's the problem.
- xena 5y agoAuthor of the post here, yeah for the admin tooling that I derived this from I actually do use "components" (functions that turn javascript objects from an API into HTML elements), but the real reason I discovered this was because I wanted to do it in a way that my Haskell and Rust-ruined brain could grok. I have a hard time with React's reverse PHP stuff but have no problem translating what I can conceptualize the DOM as in my mind into Javascript syntax using this (admittedly clunky) set of wrappers. Consider code like this: let content = div({}, [ h3(feed.title), ul(feed.items.map(item => li([ahref(item.url, item.title)]))) ]); This kind of stuff is way easier for me to deal with than the equivalent in JSX. I don't know why, but It Works For Me :tm:. It also has the advantage of not requiring a separate build step so you can just slap it into a Go binary with a go:embed directive and you're off to the races. Plus as far as I understand it's fairly idiomatic for people to reinvent their own JavaScript frameworks for when they need something between JQuery and React. Xeact (zi-act) is designed to fill that gap. Serve with laundry sauce.
- gorgoiler 5y agoYou might be interested to know that in the alternate universe of Phabricator — the magnum opus of a PHP codebase that is the fourth cousin twice removed of Facebook’s internal PHP stack — there was a function not unlike the one you describe: https://github.com/phacility/libphutil/blob/034cf7cc39940b935e83923dbb1bacbcfe645a85/src/markup/render.php#L24 https://github.com/phacility/libphutil/blob/034cf7cc39940b93... It’s verbose but I learned a lot from it. For example, returning a more specific type than String can eliminate a large class of security / escaping bugs.