This is certainly new to me and something I'm going to play with a bit. Thank you for sharing this here.
Building a front end framework – Reactivity, composability with no dependencies
61–70 of 80 posts
Re: Building a front end framework – Reactivity, composability with no dependencies
#62Enjoy 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. H…
> This removes the need for VDOM diffing, but unless I use a `MutationObserver` external updates to marked branches will probably mess it up.
Similar in Reken. It controls all the DOM; DOM updates outside Reken will get stuff out of sync. After a model change, all managed DOM gets directly updated by a generated controller. It does check the DOM first if a textContent or attribute change is necessary. Most DOM state checks are cheap. Another optimization is that all hidden DOM trees get skipped; Great in SPA apps with multiple pages.
Re: Building a front end framework – Reactivity, composability with no dependencies
#63They literally just described Svelte with that headline. Front end framework: check Reactivity: $check Composability: check No dependencies: once compiled, check And pretty sure Svelte (or Qwik or Solid or even React) will perform better than the "dependency-free" custom components. The open secret in the front end world is that custom components as baked into browsers is slower and a major pain in the ass as an API.…
I love Svelte for all these reasons. But in the end, was turned off by the required tooling.
Re: Building a front end framework – Reactivity, composability with no dependencies
#64Earlier quoted context omitted.
I've worked on quite a few projects that would have had significantly worse user experiences if they were done in a purely SSR driven way: * Chat applications, or anything where you need to have the UI react to incoming events from a socket. * Applications where sensitive data lives in the client and you don't want to be liable for that passing through your servers. * Anything dealing with video or audio (e.g. video…
* Applications where sensitive data lives in the client Isn't JS the worst kind of solution for security related things?
In what way?
Re: Building a front end framework – Reactivity, composability with no dependencies
#65Earlier quoted context omitted.
I've worked on quite a few projects that would have had significantly worse user experiences if they were done in a purely SSR driven way: * Chat applications, or anything where you need to have the UI react to incoming events from a socket. * Applications where sensitive data lives in the client and you don't want to be liable for that passing through your servers. * Anything dealing with video or audio (e.g. video…
* Applications where sensitive data lives in the client Isn't JS the worst kind of solution for security related things?
E-commerce of any sort involves sensitive data (PII, credit cards, etc). Plenty of third party payment processors let you build a very nice custom looking check-out flow via provided libraries that interact with popular frameworks. Your server never sees any sensitive info.
None of them require using those frameworks, of course, but they can make life easier.
Re: Building a front end framework – Reactivity, composability with no dependencies
#66Enjoy 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…
Your arrays and buttons example appears broken - after the first item is added to the todo list, typing new items in the input field leaves the add button looking disabled (although it works when you click it). I think it only gets enabled when focus leaves the input field.
Fixed :-)
Re: Building a front end framework – Reactivity, composability with no dependencies
#67New front end frameworks that claim leaps in simplicity feel like the violate some kind of no free lunch principle to me. If they’re that simple, then I’m willing to bet they make some use cases very difficult or impossible
I would argue rather that the amount of complexity that frontend web devs put up with is more of a Stockholm Syndrome situation. You can be much simpler than most mainstream frameworks, using only standard JS, CSS, and HTML, and acheive better results. Using custom elements and shadow DOM like this post is a big part of that. Custom elements give you a built-in component module, shadow DOM gives you compositions and…
Rather I feel like there's a now fairly well known set of requirements, and every so often, a new framework comes around and says: "It's simple, we just don't consider this."
For instance, the controllers introduced in Lit 2.0 feel like an admission that you forgot to consider the reasons why React moved away from classes in the first place. The example [1] could be written in less than half the amount of lines with hooks, and isn't any easier to understand. Also, I can't find a solution for skipping expensive computations when re-rendering the component.
Admittedly, I only skimmed Lit's documentation. But with the frameworks that I have tried, I came across cases where I had to either implement my own workaround, or the framework began introducing more and more concepts to fix their fundamentally broken approach (cough Aurelia).
Re: Building a front end framework – Reactivity, composability with no dependencies
#68Please don't make websites dark mode only. This is terrible for accessibility. I have astigmatism and can't read more than a few paragraphs. https://medium.com/@h_locke/why-dark-mode-causes-more-access... If the issue is not wanting to spend a bit of effort to implement prefers-color-scheme then light mode is a much better default option.
I have astigmatism with the opposite effects. I wish more sites had dark modes. I have to use dark reader to ensure I can have a dark page but that doesn't always work.
Do you use your devices in a well lit room?
Re: Building a front end framework – Reactivity, composability with no dependencies
#69Earlier quoted context omitted.
The law of leaky abstractions - as systems become more complex eventually you rely on more abstractions that try to hide complexity. What makes it worse in the front-end framework world is that either: 1-Projects become convoluted with 3rd party libs to solve a problem 2-The framework maintainers eventually introduce APIs that aren't backwards compatible and existing ones stranded or deprecated
When discussing this problem with ChatGPT it indeed said the best solution for this is for frameworks to be designed in a way that encourages extensibility: so a framework should stick to its core principles but allow “plugins” to extend its functionality for very specific use-cases. But I understand there’s always a trade off here, as simplicity in the framework shifts the complexity to the application.
One example of a framework that takes this approach is Apache Royale. It’s a reboot of the AS3 language and component library that works like Adobe/Apache Flex but compiles to JS targeting the browser runtime. This refactored Flex was rebuilt from the ground up with a Pay As You Go (PAYG) philosophy where components are composed of „beads“ on a strand that enable composition of the functionality you need rather than the kitchen sink.
Re: Building a front end framework – Reactivity, composability with no dependencies
#70Earlier quoted context omitted.
Have you tried Lit yet? It gives you a reactive base class and declarative templates. Plain JS and no build step (or you can use TypeScript).
I played with it a little bit when you told me a few months ago it supports buildless.[0] The thing that dissuaded me is that it seems like it forces me to write my template HTML in strings, so I lose VS Code syntax highlighting and Prettier auto-formatting. I tried looking for VS Code / Prettier plugins but didn't see anything. Is there a way in Lit to write the templates in regular HTML rather than a string? [0] ht…
The lit-plugin in for VS Code offers syntax highlighting, jumpt-to-definition, etc: https://marketplace.visualstudio.com/items?itemName=runem.li...
Prettier already supports HTML in html`` strings, likewise, CSS.
> Is there a way in Lit to write the templates in regular HTML rather than a string?
This would require a compiler. You would need to load the HTML into the JS module graph and JS can't do that yet, though there is a proposal for it: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
Template in HTML also have the problem of the data not being in scope as it is in JS, and there not being an expression language. So you ned up having to re-implement a lot of JS embedded into the HTML syntax, which then preferences a compiler-based approach to make fast. It turns out to be a lot simpler to embed HTML in JS.