Was about to say that it's also a lightweight orm for .net, but apparently that's called dapper and I could swear it was dagger.
taosx 4 hours ago [-]
I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me.
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
Isn't that what Svelte was aiming to do? It's moved on a ways since then, but you can still see the fundamentals in its demos: https://svelte.dev/playground/hello-world
harrygeez 3 hours ago [-]
I’m in a similar boat like you. I would love for a React-like library that compiles down to direct JavaScript DOM transforms. Of course Svelte exists but I don’t want to mark what is reactive or not and I can’t go back to html templates after using typed JSX. Also I don’t really like the “island” like template syntax of Vue, Svelte, etc
If what you're looking for is JSX and TypeScript (but without magic or reactivity), there's something I wrote here: https://webjsx.org
omtinez 1 hours ago [-]
Nice work! I'm also a fan of the runtime only frameworks. They might not be as efficient as the compiled counterparts on paper, but in my experience the performance loss is almost negligible compared to the rest of the stack.
I don’t get it. The native js Dom api has a lot of sharp edges but do people hate it that much abstract away from it?
Personally I rather have zero runtime code along side zero build by learning truly native js dom
mkoryak 4 hours ago [-]
Seems neat. I wouldn't use it for personal stuff because I'd be afraid of getting locked into a framework that might not exist next year.
Once this project is about a year old, if it still has any commits, then I'd consider it.
wffurr 4 hours ago [-]
Seems like it’s been a while since a new JS framework landed on the front page.
ivape 3 hours ago [-]
The last decade gave us enough JavaScript for a lifetime.
Nickersf 59 minutes ago [-]
Exactly, we also have to think about support and maintenance when building and shipping products. It's always nice to play with new things to keep the learning fresh and see what people are up to. I started with php and .NET Framework ASP and in the early-mid 2010's when the reactive JS frameworks started coming around I just never found my jive with them and just started working at C#/.NET shops and am using Blazor Server now. For my domain of web application development the .NET web application ecosystem works great. Looking at the dagger.js docs and examples found myself thinking, this is more Java(SCRIPT) development. It's going to inherit the same issues as JavaScript (weak typing, no runtime reflection, no binary build output, locked into vendor interpreters with mixed feature support), and that's not mentioning all the oddities with the way object prototypes are implemented and interact with each other. I think the ambition and result of the project are amiable. The author did good work, but it's good work on a thing we need less of in my opinion.
TonyPeakman 5 hours ago [-]
thanks for taking a look!
Positioning: Think Alpine/Vue-like ergonomics but no build and WC-first.
Size & perf: Focus is on simplicity and startup latency over framework features. I’m not posting synthetic benchmarks; if you have a real page you want me to try, I’ll profile it and share results.
Interop: Works with native Custom Elements. I’m preparing examples with Shoelace/FAST.
Security: Directives are sandboxed; no eval. If you spot an injection risk, please open an issue and I’ll patch quickly.
Limitations: Complex state management, SSR/streaming, and huge SPA routing aren’t first goals.
License: MIT.
Contrib: Issues and small PRs welcome (docs, examples, tests especially).
I’ll stay in the thread to answer questions and incorporate feedback into the docs.
Is this aimed at being in the same role as petite-vue and alpinejs? They also don't have a build step.
I've started to think something like petite-vue and twind would let you build small internal tools quickly, there are some major downsides to it which is why I haven't committed yet.
mythz 3 hours ago [-]
Using the full vue.js doesn't have a build step either.
I started out developing UIs using petite-vue, unfortunately ended up rewriting it to use full Vue.js after running into too many of its limitations and issues, which given that it's abandon-ware wont ever be resolved. As such I'd strongly recommend against starting projects with PetiteVue and just use the ESM build of Vue.js which also doesn't require a build step, has the full feature-set, is actively used and maintained, etc.
Either way developing Web Apps (using Vue) without a build step using JS Modules is now my preference which I've written about in my Simple, Modern JavaScript post [1]
I think your site broke? Also, I'd scoop up daggerjs.com while you're at it.
Link to the DI mentioned by the parent comment https://github.com/google/dagger (also Apache 2)
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://github.com/facebookarchive/prepack
https://solidjs.com
Shameless plug to my own runtime (and compile) micro framework: https://github.com/fresho-dev/mancha
Personally I rather have zero runtime code along side zero build by learning truly native js dom
Once this project is about a year old, if it still has any commits, then I'd consider it.
Positioning: Think Alpine/Vue-like ergonomics but no build and WC-first.
Size & perf: Focus is on simplicity and startup latency over framework features. I’m not posting synthetic benchmarks; if you have a real page you want me to try, I’ll profile it and share results.
Interop: Works with native Custom Elements. I’m preparing examples with Shoelace/FAST.
Security: Directives are sandboxed; no eval. If you spot an injection risk, please open an issue and I’ll patch quickly.
Limitations: Complex state management, SSR/streaming, and huge SPA routing aren’t first goals.
License: MIT.
Contrib: Issues and small PRs welcome (docs, examples, tests especially).
I’ll stay in the thread to answer questions and incorporate feedback into the docs.
Thanks
https://www.whois.com/whois/3.33.130.190 and https://www.whois.com/whois/15.197.148.33 are AWS
https://www.whois.com/whois/185.199.109.153 and similar are GitHub and is almost certainly this repo https://github.com/dagger8224/dagger8224.github.io/blob/main...
Will check out the repo linked at the end of your message.
I've started to think something like petite-vue and twind would let you build small internal tools quickly, there are some major downsides to it which is why I haven't committed yet.
I started out developing UIs using petite-vue, unfortunately ended up rewriting it to use full Vue.js after running into too many of its limitations and issues, which given that it's abandon-ware wont ever be resolved. As such I'd strongly recommend against starting projects with PetiteVue and just use the ESM build of Vue.js which also doesn't require a build step, has the full feature-set, is actively used and maintained, etc.
Either way developing Web Apps (using Vue) without a build step using JS Modules is now my preference which I've written about in my Simple, Modern JavaScript post [1]
[1] https://servicestack.net/posts/javascript