Building a front end framework – Reactivity, composability with no dependencies
1–10 of 80 posts
Re: Building a front end framework – Reactivity, composability with no dependencies
#2This is extremely similar to https://jhuddle.github.io/ponys/ which I've been using quite happily. The `data-mark="foo"` convention is interesting, similar in spirit to ng:bind or knockout attributes.
Re: Building a front end framework – Reactivity, composability with no dependencies
#3Very interesting. I think this explains a lot of the magic that happens under the surface in the frontend frameworks. I quite like the approach you are using to avoid a build step and also zero dependencies.
Re: Building a front end framework – Reactivity, composability with no dependencies
#4Nice writeup. We're working on a framework with similar goals, here: https://github.com/frameable/el
Reactivity, composability, templates, etc with no dependencies, in ~150 SLOC.
Re: Building a front end framework – Reactivity, composability with no dependencies
#5This is great! I've been looking for a framework with exactly these goals. I've been using vanilla JS and custom elements and feeling like I'm writing too much boilerplate, but all the frameworks I've tried are too heavyweight.
Re: Building a front end framework – Reactivity, composability with no dependencies
#6Enjoy the process of building your framework. I had similar goals when I started my no tooling / no dependencies Reactive framework https://reken.dev, 2 years ago. And I loved every bit of it. My most complicated problems were reactive DOM elements based on nested loops and recursive components. Even though Reken does pretty much what I need and grew to 7kb compressed, I am not 100% happy with the scope of the application state, and it is simple but sometimes confusing. Perhaps your proxy approach can help me here.... I'll have to think about it more.
Re: Building a front end framework – Reactivity, composability with no dependencies
#7Enjoy the process of building your framework. I had similar goals when I started my no tooling / no dependencies Reactive framework https://reken.dev , 2 years ago. And I loved every bit of it. My most complicated problems were reactive DOM elements based on nested loops and recursive components. Even though Reken does pretty much what I need and grew to 7kb compressed, I am not 100% happy with the scope of the appli…
> My most complicated problems were reactive DOM elements based on nested loops and recursive components
Agreed, I've tried solving it by setting an attribute `sb-mark` which allows syncing just the branch of DOM elements that maps to that particular key in the reactive object.
This removes the need for VDOM diffing, but unless I use a `MutationObserver` external updates to marked branches will probably mess it up.
Haven't yet tested it for recursive components, it should work for nested loops.
> and it is simple but sometimes confusing
I understand what you mean, my approach has the aforementioned `sb-mark` attribute/directive which syncs primitives, lists, and objects.
I've started feeling that the convenience of having just one attribute to remember is supplanted by the confusion of its implications not being immediately apparent from context.
Re: Building a front end framework – Reactivity, composability with no dependencies
#8Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.
Re: Building a front end framework – Reactivity, composability with no dependencies
#9Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.
Projects that don't need a lot of interactivity after rendering definitely don't need one and you can get away with rendering everything in the backend.
Other projects need some additional features that must be implemented in the frontend, but still don't need more than vanilla JS or jQuery.
Others might need more complex components, such as datepickers, carousels, interactive charts, interactive tables, accordions. But even those can be consumed from third-party components without a framework. A middle ground is writing your own encapsulated components.
However there are more complex apps that do benefit from frameworks. It's often because they have a lot of custom components and a framework really helps; and/or because they're not really divided into pages in a traditional web way, so rendering on the backend is significantly harder; and/or they have a lot of shared state between multiple areas of the screen, and not refreshing is easy than caching or re-fetching. All those among other reasons. Slack Web can benefit from this. Your daily CRUD not so much.
Whether people are using the right tools for each job is up for debate. And sometimes you'll have incorrect requirements. But there are definitely reasons to use more complex/flexible tools.
Re: Building a front end framework – Reactivity, composability with no dependencies
#10Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.
They were extremely useful before browsers had certain features, like web components of the Proxy api mentioned in the article.
Today the argument is usually based on highly complex apps, think complex dashboards accessible behind a login or browser-based apps for recording a podcast. Those are reasonable uses for client-side frameworks - the problem is they are often used for much more basic sites that just need a mobile menu, accordion component, or a dialog modal. All of these can either use entirely browser native HTML/CSS or easily built in JS without any dependencies.