Show HN: I built a 4kb alternative to React, Vue, etc for building web UIs.

I like the docs because, having come from a different dev environment, and seeing web/html as a vast sprawling landscape of surface area to learn, littered with defunt, old, broken, and janky throwaway bits everywhere - the documentation implicitly points out the core path of what's needed to understand how to bind and work with data in a web page.

Bravo!

I'm convinced this clarity comes from you distilling down what exactly _are_ the core pieces, and only implementing them first.

some rambling questions:

I wonder how this (synergyjs) works for a webapp type situation? Would one extract .js scripts as modules to reuse custom components? or is that trying to bring this into a more complex setup than is the sweet spot for this lib? e.g. is this better suited for a page at a time?

Also, maybe I'm dense, but does this approach lend itself to single page apps? My understanding is it shines when you have single pages with some logic behind them. If you need to jump to another page, the "passed data" would be encoded in the url, yes?

(I seem to recall the html 5 standards were looking to add something (was it 'proxy'?) that was something like frames, but involved web components, and maybe even passing of data through slots... is that a thing?)

https://preactjs.com/

I tried Preact a few weeks ago and the examples all worked, which was nice. And there's no build step -- you can develop with a CDN and hit F5. Big win IMO.

https://news.ycombinator.com/item?id=25391077

- it has a bunch of useful serialization sugar (e.g. `{{ classes }}` serializes correctly whether it's an array, an object of booleans, etc. This is similar to Angular (in React-land, this got pulled out into a separate package, classnames). There's similar sugar for `style` and objects (which React also supports).

- I'm not a fan of the variadic event handler signature. If I understand correctly, having a event handler inside a loop adds an extra argument to the handler function, but what happens if there are nested loops? In React-land, this would be done w/ arrow functions and closures; in Angular, one would write a js function call similar to plain HTML event handlers. I prefer the React approach (though I understand that isn't really an option for the way you approached synergyjs)

- Similarly, if `#` is bound to loop index, then how do you access outer loop index in a nested loop situation?

- Binding view property names to form controls of the same name is an interesting abstraction. React looks clunky in comparison (yes, even hooks). Angular has a similar facility, with the addition of allowing custom transformation logic (think getter/setters for bidirectional bindings).

- prerendering via a browser-like environment isn't the best approach IMHO (I've seen people run into issues w/ jsdom missing features, for example, and something like puppeteer is a bit of a heavy thing to be running frequently server-side)

- I like the clear separation between JS and CSS (but, then again, I'm an old school person). React people might dislike it if they're used to css-in-js per-component style encapsulation.

Overall impression: appears to pack quite a punch for 4kb (more so than Preact IMHO, because of how it handles forms). Docs are clear and to the point, but could use more examples/tutorials (especially lifecycle hooks). Would like to see it mature a bit (e.g. in terms of addressing things like nested loops, as mentioned above), and I think it would benefit from considering a less expensive SSR approach.

Very promising!

What I realized is, "who would add something unnecessary anyway?".

I mean developers would think of keeping it as thin as possible. Just that over the time, we run into senarios that need extra codes. Otherwise, users would think about alternative solution. And in web development, it very likely to happen

Hope that you work out the real competitive advantage

By the way, in terms of bundle sizes React is smaller and Preact is almost the same. But I think the reason is that react-dom is not included into calculation https://moiva.io/?compare=Synergy+preact+react+synergy+vue

When there are plenty of unknowns and you're working solo, you need a very thin layer that lets you craft a prototype quickly and not spend too much time configuring or generally investing a lot because it's something you plan to keep for a short time anyway, or it has a small scope that is never expected to grow. I think this framework kind of fits this model.

In a corporate environment, on the other hand, you're probably building something with the intention to last and then you need something that is established and has rigid interfaces, off-the-shelf components and Stack Overflow activity. Ideally, a framework that can only produce one style of code so that the next person or the next team can pick up.

Another possibility is you're on a budget, a handful, but know-their-way, developers and there is no plan to scale that for the foreseeable future. You want to try out ideas and be able to fail quickly. If you use React and TypeScript for your prototypes, you'll get a sound and solid codebase but also one that also cost you a lot of time. So, if just before the end and a couple of months in you discover you need to do some dramatic changes, you are left with little options and an empty budget.

Each needs to do their research and decide based on their unique requirements and more frameworks = more options, easier to find a fit. In my opinion, use the big frameworks only when you have a clear concept of what you're building. Otherwise, use something that gets the thing done as painlessly as possible.

Edit:

In addition to that, the world changes, and our concept of what is the proper way to build UIs or even what constitutes a good UI changes, as the world and the people change and new technologies emerge. If we aren't exploring ideas at the edge of our undestanding and knowledge, then we'd still be writing <font> tags in our Geocities pages.

I have no affiliation, just happened to notice it and really really like its philosophy, framework builder, readable code, and documentation.

I hope Andrew sees this comment so he can chime in.

https://gitlab.com/andrewfulrich/barleytea

Now I just need to find a project to use this on.

Are you using it in a project of yours?

[0] http://celebio.github.io/Yama.js/

And React is only about 5kB unless I'm mistaken?

FYI, I wrote something similar a couple of years ago but never took the time to publish a repo...

I like how your templating language is minimalistic (not embedding whole js syntax inside) and is valid HTML (could be prepared using HTML authoring tools).

I have few remarks comming from my expeirinece in wirting and using minimalistic templating engines.

--

This templates tightly integrate with html and magically interpret the view model values depending on the context they are used in html.

I think it could be better to explicitely indicate in place of use that the value will not be used directly.

Not

    <div hidden="{{hide}}">

    <div :hidden="{{hide}}"> 
    <div _hidden="{{hide}}">
    <div :hidden="hide">

---

Passing current item from `#each` loops into event handlers implicitly is very cool, but you might want to think about what if you have nested loops.

Maybe it would be cooler to pass not just the element but sort of `context` object that contains current elements of all nested loops and perhaps some other stuff in the future?

Also you might consider passing it not only into event handlers but all functions called from template.

Again you could use `:onclick` instead of `onclick` to indicate that there's some additional magic happening.

---

You might want to consider making loop variable optionally anonymous to reduce the noisiness of looping.

    <!-- #each in people -->
    <li>Hello {{ .name }}</li>
    <!-- /each -->

You could do form binding though `:name` to indicate that something beyond just usual HTML is happening and allow people to opt-out for some controls by using just `name` instead of `name`.

---

All of this could easily work with pre-rendering and hydration by not removing `:something` attributes when `something` function is called to do the appropriate magic.

But claiming is as alternative is overblown, people choose those two frameworks because the rich ecosystem and support behind it, for which, except probably Angular, there are no way around them.