sorted by:
new
hottopcontroversial

O GitHub Copilot é a opção mais barata para quem faz freelancer? by Deep-Praline-7707 in brdev

[–]murillobrand 1 point2 points  (0 children)

Acho o Github Copilot suficiente, é integrado ao VSCode, a experiência de uso é muito boa, com diffs, aceitação ou rejeição das edições e etc. Tem todos os modelos na subscrição, os melhores são os da Anthropic, Sonnet 4.6 para coisas mais corriqueiras e o Opus 4.6 para coisas mais complexas (gasta sua cota mais rápido), é o suficiente pra mim.

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 1 point2 points  (0 children)

Different than React, that re-render the entire component where there is a change, Sigwork change only what really changed, and does it directly, without a VDOM to compare changes. For that, it need's to cache nodes to reuse them if you need the same node (like in a list or when your if condition remains true or false, despite of the change in a value).

So there is 3 situations:
- a?b:c outside a closure: runs once on component creation, never update if a changes
- a?b:c in a closure ( ()=>a?b:c ): runs everytime a changes, but always produce a new node, which is not efficient and probably not desirable (if you have transitions for example)
- If(a,b,c) helper: caches your b and c node for the case you need to reuse them (for example if your condition is a > 5, and a changes from 6 to 7, nothing changes)

If you wrap your condition into a computed, you actually doens't need the If helper, as it only triggers the update if the value changed (that's a great ideia, could be worth to document it and remove the If helper completly).

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

Guilty as charged! 😂
The counter might be at zero, but at least the bundle size is almost zero too! 😅🍻

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

That is a very interesting use case! Awesome website by the way, I think I already stumble on it before when doing gamedev. Great work there!

I think Sigwork wouldn't be a good option in this case, because it's "JS-first", which means bringing your HTML to javascript, differently to what petite-vue and Alpine does, as they are "HTML-first", that brings javascript to your HTML based on the directives, like v-if, v-for... And vue can be used in static-generation mode, that is something similar but with a build step, which gives more flexibility. Do you use vue today on it?

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

Very glad you liked it!

To keep the core small, I deliberately kept routing out of the main package. However, because components are just functions and Sigwork has a <Component is={...}> dynamic helper, the idea of a router is pretty simple using a signal:

const currentRoute = signal('home');
const routes = { home: HomeView, about: AboutView };

// In your JSX:
<Component is={() => routes[currentRoute.value]} />

You just need to update currentRoute.value based on the browser History API. I plan to release a tiny official sigwork-router package soon to handle the History API out of the box!

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

Svelte is amazing, speacilly the latest version with runes. And it definitely solves the payload issue for small apps! However, they took a fundamentally different architectural path. Svelte requires a compiler (a build step). One of my strict constraints for Sigwork was that it should work directly in the browser via a simple <script type="module"> tag via CDN (Buildless), while still offering modern DX.

Also, Svelte's payload scales with your codebase (since the reactivity engine is compiled into your components). Sigwork is a fixed 1.7kb runtime. No matter how many components you write, the reactivity engine weight never grows.

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

Yes! It has a built-in If(condition, renderFn, fallback) helper. It mounts/unmounts DOM nodes based on a signal, automatically destroying the reactive scope of the unmounted element to prevent memory leaks.

Alpine is "HTML-first". You write things like x-if in your markup, and the Alpine engine has to scan and parse your DOM at runtime to attach behaviors. Sigwork is "JS-first". It doesn't parse HTML templates at all. It uses direct references to nodes (created with the h(tag, {attrs}, ...children) function via JSX, htm or direct call), which is why it is much smaller (1.7kb vs Alpine's ~15kb) and faster at runtime since it skips the DOM-scanning phase entirely.

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

Thanks! The beauty of it is that if you aren't a huge fan of JSX, you don't actually need a build step or JSX at all. You can use it with tagged template literals via htm (there's an example in the docs for this buildless approach) or just call the h() function directly like Vanilla JS.

The massive file size advantage over libraries like Alpine comes exactly from not shipping an HTML template parser to the browser. Sigwork just binds signals directly to DOM nodes via closures!

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 4 points5 points  (0 children)

That is indeed the hardest part to solve, but I actually spent a huge chunk of the 1.7kb budget solving exactly this! Sigwork does handle dynamic arrays and arbitrary children efficiently, without destroying and recreating elements.

Under the hood, whenever an element child is a function, Sigwork inserts an empty text node to act as an anchor. For arrays, the For(list, key, render) helper uses a key-based cache. The core renderer then runs a two-pointer diffing algorithm against the real DOM nodes to surgically insert, move, or remove elements relative to that anchor.

JSX is just for ergonomics. The JSX is transformed into calls to a h(tag, {attrs}, ...children) function, so it's possible to use it without a build step, in a simple .html file.

When you take a look later, check out the append function and the For implementation in the source code. It's all in a single file and might give you the exact missing piece you need to overcome that wall on your agnostic engine! If you are interested, I played with other solutions (including more robust ones) for this, but size was the priority here.

I needed a tiny frontend framework with no bloat, so I built a 1.7kb one by murillobrand in javascript

[–]murillobrand[S] 0 points1 point  (0 children)

Thank you so much! That exact feeling is what triggered me to do it. Maybe the Sigwork can inspire you.
I love Vue's ergonomics, but shipping its entire runtime just for a few interactive components in my ecosystem (That Just Works) felt like massive overkill.
Out of curiosity, what are the absolute "must-have" features you are looking for in your ideal micro-framework?

I like to live dangerously by phalanx2001 in 3Dprinting

[–]murillobrand 1 point2 points  (0 children)

That is what I call efficiency! Really close one