domdiff | go-neon | |
---|---|---|
2 | 1 | |
210 | 10 | |
- | - | |
0.0 | 10.0 | |
over 1 year ago | over 1 year ago | |
JavaScript | Go | |
ISC License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
domdiff
-
Ask HN: What happened to vanilla HTML/CSS/JS development?
> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?
You can even avoid a shadow DOM entirely:
https://github.com/WebReflection/domdiff
https://github.com/WebReflection/uhtml
-
Proposal to add efficient DOM diffing to browser
If by faster you mean faster than React I think there is evidence it can be. The author of the issue writes lots of dom utility and rendering libraries and I believe domdiff is more or less what he describes in the post:
https://github.com/WebReflection/domdiff
You can find it placed way above React in the usual JS rendering benchmarks:
https://rawgit.com/krausest/js-framework-benchmark/master/we...
Now it's not entirely clear whether these benchmarks convey something meaningful except for maybe the point that most frameworks are quite fast. That being said I think it's developer experience that really stands to improve. Thinking of view as a pure function of state was a great innovation, but existing implementations can end up fracturing the view into virtual doms and non-virtual. Then you end up with problems like D3 and React not coexisting.
I feel like I heard something from the lit-html folks that a long term aspiration was to integrate some learnings from the project into chrome, but I haven't been able to find where again.
There has been a trend in JS with libraries becoming idiomatic to the language to later have the issues they targeted be addressed natively (a la JQuery).
In general, I definitely appreciate your point about adding complexity to the platform, but I think when it comes to web technologies that ship has long sailed. I really see it as an opportunity to bring a lot of simplicity, chiefly filling that void that's birthed a billion JS frameworks.
Thanks for the thoughtful comment.
go-neon
-
Ask HN: What happened to vanilla HTML/CSS/JS development?
HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use!
[0]: https://github.com/gofiber/fiber
[1]: https://github.com/codemicro/go-neon