15 ms·
Show HN: I built a 4kb alternative to React, Vue, etc for building web UIs.
- defx 6y agoSynergy 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.
- forgotmypw17 6y agoThank you for sharing your work. I learned from reading it.
- defx 6y agoThanks for the comment, I hope you get a chance to try it out!
- forgotmypw17 6y agoI 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?
- nine_k 6y agoSupporting hundreds of different browsers? This is a noble and audacious goal, but I suspect that it would either take enormous resources, or the least common denominator approach. OTOH supporting, say, the 3 major browser engines that serve > 99% of the audience is sort of achievable, and also practical.
- forgotmypw17 6y agoa) I believe your 99% figure is way off. 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"?
- jlokier 6y agoYou 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.)
- defx 6y agoThanks 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.
- defx 6y agoRE "browser support". Synergy has support for "modern" browsers (e.g., https://caniuse.com/mdn-javascript_builtins_proxy_proxy 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.
- h3rald 6y agoThat'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 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.
- qwantim1 6y agoThis is great! But, what would you say to those that say, “Great- another year, another JS framework”? Specifically, why would I want to use this instead of Vue? What does it buy the average developer?
- onelovetwo 6y agoits fun, he probably didnt make this for your company/corporation, He made it because he likes making stuff as a programmer. I find it kinda interesting too so I might try it for my next project...thats how it goes.
- defx 6y agoThat'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.
- rk06 6y agoyou are not required to use it. And IIRC this is exactly how Vue, riot etc. started their life
- romwell 6y agoTHANK YOU. In this world of bloat, it is so refreshing to see someone doing The Right Thing.
- defx 6y agothanks romwell, glad to hear that you like it!
- fergie 6y ago"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.
- defx 6y agoThanks fergie, glad that you like the approach.
- NetOpWibby 6y agoToo bad the name "Svelte" is taken.
- defx 6y agolol
- mordechai9000 6y agoI 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?
- defx 6y agoYes! That's definitely on the todo list and would be a welcome contribution.
- farynaio 6y agoExactly. 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.
- defx 6y agoThanks farynaio, much appreciated.
- Existenceblinks 6y agoSynergy looks like "uce" here https://gist.github.com/WebReflection/761052d6dae7c8207d2fcba7cdede295 https://gist.github.com/WebReflection/761052d6dae7c8207d2fcb... But I can see you use "Template Parts" syntax. 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?) --- Just read some docs it seems like using Proxy!
- defx 6y agoThanks 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.
- defx 6y agoHere's a rough video demo showing a simple "hello world" component: https://www.loom.com/share/ffe3fb6d23264cc7ad458f6b856ddc49 https://www.loom.com/share/ffe3fb6d23264cc7ad458f6b856ddc49
- vldmrs 6y agoHi, how is your project different from alpine.js?
- sillycon-valley 6y agoalpine syntax looks very different from a quick glance at the readme. very angular-ish, template heavy with it's own syntax.
- defx 6y agoThanks for your question. I'm not overly familiar with Alpine but yes, the syntax is very different. Alpine appears to freely mix JS and HTML whereas Synergy minimises this in favour of a clearer separation of concerns.
- stanislavb 6y agoFor the record - here they are alpine.js (https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine) and synergy.js (https://github.com/defx/synergy https://github.com/defx/synergy) repos.
- onurcel 6y agoThat's really nice! I like it. I also built a minimalist ui tool a while ago [0] so I totally understand where you are coming from. Mine never really took off probably due the lack of interest of minimalism at that time, but there may be a wider audience for that approach nowadays. Are you using it in a project of yours? [0] http://celebio.github.io/Yama.js/ http://celebio.github.io/Yama.js/
- defx 6y agoThanks, glad that you like it, and I love the fact that Yama "fits in a Commodore 16"...
- gitgud 6y agoI love that demo that automatically types and renders the result, have you made a library for that? It looks like a small custom script.
- onurcel 6y agothanks! yes it's a small custom script
- chubot 6y agoHow does it compare with Preact? https://preactjs.com/ 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 https://news.ycombinator.com/item?id=25391077
- chrisweekly 6y agoPreact is (or was at one time) a nearly-complete implementation of React's APIs -- meaning a virtual DOM, etc. Synergy takes its own approach, and uses Custom Elements (from the "Web Components" standard). Edit: and synergy is also optionally avlbl via CDN for the no-tooling approach you liked in your preact experiments.
- defx 6y agoPreact is a really great project! I contributed to this myself in a very small way last year to add support for customised built-in elements. I would definitely recommend Preact if you're a fan of React. Synergy is different in a few ways, for example it uses Custom Elements whereas Preact has its own component system just like React. Synergy also separates HTML and JS concerns more clearly, making it a little more like Vue in that respect. Preact and Synergy both share this ability to work "as is" directly from a CDN without any heavy toolchain.
- docuru 6y ago> And there's no build step -- you can develop with a CDN and hit F5 Same with React. There is a production CDN https://reactjs.org/docs/cdn-links.html https://reactjs.org/docs/cdn-links.html
- chrisweekly 6y agoThis looks surprisingly well documented for such a tiny project, and reasonably complete for such a tiny runtime. Nicely done! :)
- defx 6y agoThanks so much for your comment, much appreciated.
- remram 6y agopreact (https://preactjs.com/ https://preactjs.com/) is 3kB... And React is only about 5kB unless I'm mistaken?
- gunn 6y agoReact itself is quite small but react-dom is much bigger: 121KB minified, 40KB gzipped - https://bundlephobia.com/result?p=react-dom@17.0.1 https://bundlephobia.com/result?p=react-dom@17.0.1
- hbbio 6y agoThis looks like https://github.com/Freak613/stage0 https://github.com/Freak613/stage0 combined with custom elements. FYI, I wrote something similar a couple of years ago but never took the time to publish a repo...
- deleted 6y ago[deleted]
- docuru 6y agoI used Milthriljs a few years back. Also created something similar with the goal is to create a "thinnest layer" for building UI. 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
- mark_mart 6y agoLooks easy to use. Is it possible to use with server side rendering?
- defx 6y agoYes, you can prerender in a browser (e.g., using Puppeteer) or provide a synthetic DOM (e.g., JSDOM) in Node. It's the next thing on my list to flesh out some more detail in the docs around this.
- lhorie 6y agoSkimmed through the docs. Some thoughts: - 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!
- defx 6y agoFirstly, thank you so much, this kind of feedback is extremely useful and greatly appreciated. I'll try to reply separately to each of your points for clarity...
- defx 6y agoRE the event signature: (If you raise an event from an item within a repeated block then synergy provides the data for that item as the second argument to your event handler function.) If you have a nested loop then you'll get the data item for that particular loop.
- mjgoeke 6y agoI really like this project, especially when going through the docs. Nearly all the abstractions are very clean in their approach, the only outlier being the hack of using `#each` `/each` comments to indicate looping. I suppose the HTML specs don't have anything for this yet, so one has to adapt in some way. 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?)
- defx 6y agoThank you, much appreciated. Yes, there are proposals for native templating, but i suspect it will take some time to agree on such things. I opted for comments in the end mainly to support multiple top level nodes, but they also prove helpful for place-finding when inspecting the DOM.
- defx 6y agoRE: 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.
- defx 6y agoHi 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 https://synergyjs.org/repeated-blocks). Much less hacky, and has also saved a few more bytes from the overall package size.
- ablekh 6y agoNice work, perhaps this has its niche. However, for general front-end development, I'm wondering about what are core advantages, over, say, Vue (simplicity is the only aspect that comes to mind off the bat). Considering that the size is not a huge advantage (gzipped and minified Vue 2/3 is just ~20K and even with Vuex and Vue Router is ~30K) and that Vue's large and diverse community and ecosystem makes it super attractive versus non-major alternatives ...
- woah 6y agoLooks like this uses a templating pseudolang with html comments. I had hoped that we were leaving that behind
- defx 6y agoFair 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 https://synergyjs.org/repeated-blocks) so no more pseudolang ;)
- deli6z 6y agoIs there support for a change detection ?
- IggleSniggle 6y agoShoutout to Barleytea which was posted a few months ago, which is also an alternative that comes in at 3.1kB MAX (if you opt-in all the features) AND, more importantly, comes with a great design document / explainer / framework builder. 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 https://gitlab.com/andrewfulrich/barleytea
- SftwreEngnr 6y agoPlease don't use someone's post to advertise another framework, you cunt.
- hobby-coder-guy 6y agoSo did everyone else
- turtlebits 6y agoLooks nice. Svelte is also <4kb, but it is compiled.
- mizzao 6y agoWould be also interested in a deeper comparison to Svelte here.
- defx 6y agoThanks 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.
- thunderbong 6y agoI also feel that Svelte has taken the best of many worlds. Most front-end Javascript frameworks rely on either declarative widgets or some contrived implementation of HTML / CSS with a build step to get the developer's code to render in the browser. Svelte's approach to sticking extremely close to traditional HTML / CSS & JS, and then compiling everything together, in my opinion, makes it much more approachable and maintainable.
- BatteryMountain 6y agoSvelte also feel a lot like using Knockout which was/is great (although its not a full framework)!
- rhengles 6y agoI think Rich Harris is to front-end as John Carmack is to games development, and no doubt Svelte is a marvel of technology, however I dispute the notion that it is more close to "traditional html / js / css" than either React or Vue. For example, most frameworks use webpack which extend es6 module syntax in a way that they don't work natively in the browser without compilation, and I don't think Svelte is any better than them in this regard.
- NetOpWibby 6y agoAlright, just checked it out. Using regular HTML comments for rendering many items is neat and using the hash symbol to display the index is genius. I really like that. Now I just need to find a project to use this on.
- defx 6y agoawesome, thanks! Would love to hear how you get on with it.
- narrator 6y agoJust wait. You are going to start adding modules and eventually you're going to have a whole ecosystem. Someone is going to complain about the bloat and then build the new simpler JS framework that's basically your version 1.0. I've seen this movie several times over the last 10 years.
- devwastaken 6y agoIt's a fun thing to do that lets you learn the core issues frameworks try to solve. People then post their work because we have to legitimately market ourselves and our work somehow. There's lots of avenues that can be taken with things similar to react - and trying and experimenting can create some better methods. It's not as if react or vue were built in isolation from all the previous software.
- ForHackernews 6y ago> People then post their work because we have to legitimately market ourselves and our work somehow. Wouldn't it be better if we experimented with radical new ideas for development instead of reinventing the same JavaScript wheel for 300th time?
- nailer 6y agoSvelte did this by throwing away virtual DOMs and using a compiler to directly bind elements to data.
- Xevi 6y agoWe are though. One of the current shift that is happening is that frameworks are moving away from using Webpack and so on during development. Vue now has Vite, Svelte is moving to Snowpack, etc. This can speed up development iteration time by orders of magnitudes.
- worldsayshi 6y agoI agree that that would be swell but sometimes you have to practice the same movements as those that came before to learn something new?
- deleted 6y ago[deleted]
- lolive 6y agoIsn't it LitElement reinvented?
- defx 6y agoHi 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.
- lolive 6y agoIn their technical approach? Could you elaborate on that point?
- defx 6y agoI 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.
- lolive 6y agoThat’s a very nice summary. Thanks for this clarification.
- Cyber_squad 6y agoYou should work on your landing. I really appreciate the idea and I personal feel the minimalistic design you have behind this concept and the landing page it try to promote, but still the page should be a little more wow (it's complex and fast) and the description is so minimal, and this make me wonder what can I build with this framework.
- defx 6y agoThanks 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.
- onion2k 6y ago3.8KB over the wire and 9KB uncompressed. That puts it in very similar territory to Preact. That's pretty good. I'd rather use Preact because that gives me access to the React ecosystem, but this is definitely worth considering if you don't need any other resources.
- alexey2020 6y agoJust noticed there is already existing another Synergy framework and "Synergy" package. Probably better to rename the library to avoid confusion. 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 https://moiva.io/?compare=Synergy+preact+react+synergy+vue
- cpach 6y agoAs time approaches infinity it will be harder and harder to find unique project names...
- cube00 6y agoI'm sure we can keep adding names...this project can be SynergyExcelsior
- alexey2020 6y ago))) How about SynergySuperior? ;)
- defx 6y agoThanks 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.
- alexey2020 6y agoI mean there are 2 npm packages now - synergy and Synergy https://www.npmjs.com/package/Synergy https://www.npmjs.com/package/Synergy Moiva.io shows names of npm packages
- defx 6y ago
- karmasimida 6y agoNot to talk you down, it is never-the-less good thing to build things. 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.
- defx 6y agoThanks 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 :)
- scotty79 6y agoThis is a very cool experiment and possiby a tool. I have nothing to comment on custom html elements, binding or flow but templating engines always interested me. 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}}"> but <div :hidden="{{hide}}"> <div _hidden="{{hide}}"> <div :hidden="hide"> This would make it explicit, aria would not need to be an exception and HTML and your syntax would be clearly separated. You could just pass argument through funcion named `hidden` (or `class` or `style`) and even make whole thing pluggable with custom functions that preprocess the argument into the attribute. (Or even multiple attributes if necessary). --- 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.
- defx 6y agoThanks 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.
- 6y ago
- deleted 6y ago[deleted]
- imvetri 6y agoThanks for working on this a sharing it public. Keep going.
- defx 6y agoYou are more than welcome and thanks for the words of encouragement imvetri!
- stagas 6y agoI don't understand when people complain about Yet Another Framework. There isn't a single solution to everything. 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.
- defx 6y ago"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.
- anthonysarkis 6y agoI'm curious why less features is a goal here? I wish VueJS had more features, or at the very least more tooling. Vue has progressed a lot but there is so much more room https://github.com/vuejs/vue-devtools https://github.com/vuejs/vue-devtools
- jeerovan 6y agoFew questions: Have you compared the performance? With others (React,Vue etc) Is it compatible with minification? Nothing breaks? Better than the others in managing live dom elements?
- defx 6y agoHi 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?