Synergy is my attempt to create the thinnest possible layer of abstraction over the browsers built-in APIs in order to build UIs with Custom Elements. I wanted to be able to express UIs in simpler terms, and I feel like I've achieved what i was aiming for with this. It won't be suited to everybody's tastes, and that’s fine, but I’m having a lot of fun using it myself at the moment and I'm excited to share this for the first time and welcome any and all constructive feedback.
That's the spirit! It doesn't really matter whether this will become the next (p)React, as ling as you learnt something from building it and you are enjoying using it.
And yes, I did create something like this but I wanted to include also a router (like Mithril) and a standardized way to handle state, both global and local... and I ended up with https://h3.js.org -- yep, probably not many people use it but I have been using it for months for personal projects and I keep tinkering to improve a little bit whenever I find I need to polish some rough edges or support additional use cases.
Like others said, I wonder how long it will take for bloat to creep in. For now though yes, I agree that you really don't need much code to build a fully functional SPA. And creating your own micro framework really helps you understand how things really work, without relying on someone else's abstraction.
"Synergy is my attempt to create the thinnest possible layer of abstraction over the browsers built-in APIs in order to build UIs with Custom Elements."
A noble goal. I like that you are avoiding compilation and tooling.
I find it interesting, but I'm biased against frameworks because I've yet to see one which claims to support every JS browser, which is one of my objectives.
For example, Opera 12 (Presto) has full modern DOM support with .createElement and such, but I doubt your framework would work with it?
There are hundreds of browsers and engines out there, and I want to support them all. Would your framework degrade gracefully in a browser you've never tested before?
Also, how do you deal no-JS users? I read through the documentation, but could not seem to find one?
b) I believe the remaining 1% matters, perhaps more than the others. (See wheelchair analogy.)
c) Yes, it does take a least common denominator approach at first, but you can build a lot on top of that, carefully, without upsetting even such classics as Netscape, Mosaic, and IE4.
Would you say that one developer working part time for a couple of years is "enormous resource"?
You are going to have a hard time running JS Custom Elements or even the DOM on Mosaic!
IE4 had an early DOM but it was different from the current one, and JS syntax was different too.
Writing DOM-modifying code that does useful things on IE4 as well as on current browsers is possible, but requires a lot of extra code and testing for little gain, and will encounter browser bugs if you do anything complicated, so you can't just drop in a thoroughly-portable framework, you need to test as well.
If what you mean is you'd like graceful fallback to a decent non-JS page on ancient browsers, that's doable, but then it doesn't matter if the JS framework only supports 99% of browsers. Just make sure to disable the framework on browsers too old to use it. (You'll still have a hard time with CSS on Mosaic.)
RE "browser support". Synergy has support for "modern" browsers (e.g., https://caniuse.com/mdn-javascript_builtins_proxy_proxy). It would certainly be feasible to provide a legacy version to provide support for some older browsers. Thanks for asking the question though, I should call out "browser support" in the docs as well as the github page.
Thanks for your questions. RE "no-JS", I have prioritised support for prerendering so that synergy can be used for progressive enhancement. Its early days so the docs are very minimal at the moment, but I will certainly be adding much more detail around this and I'm really happy to hear somebody raising this question as it's a valid concern that often get overlooked.
Can you explain, what technique you use to update DOM (I'm lazy to walk through code base), is it proxy object like Solidjs, or something like "uhtml". How do you manage to dispose event listener internally (is memory leak possible around that?)
Thanks for your question. Yes, that's correct - Synergy uses Proxy to detect change on the object and then simply walks the tree and updates the nodes whose bindings have changed. Yes there is some commonality with µce API due to implementation of the Custom Element lifecycle methods.
That's right, you really have to do this for the love of it when nobody is paying your bills in return. Would love to hear how you get on with it if you do get a chance to try it out.
I love that it has zero dependencies! Is there any chance that typescript definitions will be added, or would you be interested in seeing a pull request?
Exactly. I just realized exactly the same. There is no external dependencies in runtime. I think author should add this is as a one of the biggest benefits/features. Congratulations on delivery.
