defx

Hi mjgoeke, an update RE the "hack of using #each", synergy is now using <template each="item in items"> since v2 (https://synergyjs.org/repeated-blocks). Much less hacky, and has also saved a few more bytes from the overall package size.

Fair comment. Approach to repeated blocks is something I wasn't sure about, but synergy is now using <template> since v2.* (https://synergyjs.org/repeated-blocks) so no more pseudolang ;)

Hi jeerovan, thanks for the questions. RE "minification": yes, - there's a minified version (terser) as part of the build and it should also be compatible with closure compiler. RE "performance", no I haven't made any comparisons using benchmarks, if that's what you mean. DOM updates are batched together using requestAnimationFrame and the update cycle walks the tree to perform the updates, so that should give you some insight into the trade-offs. RE "better than others at managing live DOM elements": better in what sense?

I haven't looked too closely at Lit source code recently so I couldn't really comment on that but, from a high level, they differ in the sense that lit uses render function (like react) that mixes HTML/JS whereas synergy separates the two between view/template. Neither is better or worse of course, its all about trade-offs and preferences. Lit elements are described with classes whereas synergy uses factory functions. Lit uses Shadow DOM by default, whereas synergy makes it optional.

Thanks farynaio, much appreciated.

Thanks for the kind words. I completely understand the cynicism, especially when it comes to the front end / javascript scene. I'm not entirely sure if the title I chose has helped or hindered more, but it has fuelled some discussion at least and I've got some good feedback and even a first contribution, so it's definitely been worthwhile.

Thanks karmasimida, you're right; synergy is in its infancy and it has zero ecosystem or community, so when I say "alternative" the context is purely limited to synergy being an alternative approach to building UIs, that's all :)

Thanks Scotty, you communicated these ideas very clearly and this all makes perfect sense to me. One of my main goals with Synergy is simplicity, which in the context of this discussion would mean a lower level of configurability / customisation, so pulling that template functionality out and moving decisions on to the user would (as you say) take the design in quite a different direction. A perfectly valid direction though, and one that would doubtlessly better suit some folk more than my approach - I'd love to see you fork Synergy and implement these ideas!

Hi lolive. In one sense, yes! Synergy and LitElement both seek to achieve the same primary goal, which is to make it easier to work with Custom Elements. Aside from that, the two projects are quite different in their approach.

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.

"There isn't a single solution to everything". Amen to that. Some libraries suit peoples ways of thinking more than others in the same way that some people like Java and others like LISP.

You are more than welcome and thanks for the words of encouragement imvetri!

RE "Also you might consider passing it not only into event handlers but all functions called from template": By design, there's no support for calling functions from templates other than via event handlers, or via getters (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), which are treated just like any other property as far as the template is concerned.

Thanks Scotty, your feedback is greatly appreciated! Yes - with nested loops you simply get the datum for whichever block item raised the event, nested or not.

well, there's only one "synergy" that you can install from NPM, etc, but yeah - it's crazy that NPM site is working in that way because the other project has a project name that doesn't match its package name. I'll be sure to raise a ticket for that this afternoon so thanks again for pointing it out!

I've seen that too, but there are also tons of projects that stay true to their original intentions and it wouldn't make sense (to me at least) to morph synergy into a "one size fits all" framework. It has a clear set of responsibilities and my ultimate hope for this library is that it will be eventually become redundant as all of the features it provides become a part of the web platform itself.

Thanks for your interest Mizzao. Svelte is a cool project, and the discussion RE buildtime vs runtime raise some great questions RE trade-offs. What I would say is that neither project would be the right choice for every use case. Svelte is very feature rich and provides more of a “batteries included” framework approach, whereas Synergy has a much smaller feature set and scope which leaves flexibility and choices in other areas. In this sense, Synergy is easier to compare feature-by-feature with a library of smaller scope such as Preact.

Thanks for your comment. The synergy you're look at there appears to be "@onenexus/synergy" rather than "synergy". It's a shame that the comparison doesn't use the actual package name to avoid such ambiguity. If you look again at the moiva link, the results show "synergy" at position 4. Hope that helps to clarify.

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.

Thanks fergie, glad that you like the approach.

awesome, thanks! Would love to hear how you get on with it.

Apologies for the late reply, finally I had to get some sleep! No, you only get the datum for the loop from which the event is raised.

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.

thanks romwell, glad to hear that you like it!

awesome, thanks Xevi! would love to hear how you get if you do get around to that.

Thanks for the feedback. Yes, there's lots of work to do to make the docs "complete", not least some decent tutorials. It certainly isn't the "finished product" but I'm really glad that I decided to share it here on HN as the feedback is going to help me a great deal to understand where best to focus my efforts.

lol

Yes! That's definitely on the todo list and would be a welcome contribution.

RE: Would one extract .js scripts as modules to reuse custom components? Yes, you can certainly do that. the define function supports both template element nodes or strings, so you can work directly in a HTML document (the web will be getting HTML imports before too long) or do it all in JS and publish to NPM.