Live data from Hacker News

Building a front end framework – Reactivity, composability with no dependencies

18alan.space

51–60 of 80 posts

Re: Building a front end framework – Reactivity, composability with no dependencies

#51
post #21
post #14

New 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

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.

Re: Building a front end framework – Reactivity, composability with no dependencies

#52
post #38

Please 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.

Re: Building a front end framework – Reactivity, composability with no dependencies

#53
post #17

Earlier quoted context omitted.

I've found that if they brag about how easy it is to get started, it usually ends up messy relatively quickly. On the other hand, if they brag about being easy to order when you have a lot of code, it's usually a bit harder to get started with. It's like you get to chose one of "get started quickly" or "remain quick enough on the medium/long term"

Not always, some can hit the sweet spot of being simple in all phases of development and quick to learn. They are super rare though and their lessons are forgotten; industry often standardizes on inferior things with better marketing.

[deleted]

Re: Building a front end framework – Reactivity, composability with no dependencies

#54
post #17

Earlier quoted context omitted.

I've found that if they brag about how easy it is to get started, it usually ends up messy relatively quickly. On the other hand, if they brag about being easy to order when you have a lot of code, it's usually a bit harder to get started with. It's like you get to chose one of "get started quickly" or "remain quick enough on the medium/long term"

Not always, some can hit the sweet spot of being simple in all phases of development and quick to learn. They are super rare though and their lessons are forgotten; industry often standardizes on inferior things with better marketing.

> industry often standardizes on inferior things with better marketing.

It standardizes to what’s cheaper on their eyes, sometimes in a very short-sided way, but also companies that work for profit never know if a project will still be running in the next quarter, right? It makes me think that open source and for profit companies should have very different considerations when it comes to choosing frameworks or technologies for their solutions. I should probably gather more info on that and expand it into a blog article.

Re: Building a front end framework – Reactivity, composability with no dependencies

#55
post #14

New 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…

Do you have an example of a complex widget being implemented in a simpler way with better results? I see this sentiment often here, but most examples are toy examples or frivolous.

Re: Building a front end framework – Reactivity, composability with no dependencies

#56

Nice write-up, I look forward to seeing how Strawberry progresses. I keep a list of JS front end frameworks where no build step is required at https://unsuckjs.com/ . I'll add this there (and a few of the others mentioned in the comments here).

Lit 2.x is compatible with IE11, btw. We're actually removing that in the upcoming 3.0 branch though.

Thanks for the correction. Just updated it to be accurate... for now. :)

Re: Building a front end framework – Reactivity, composability with no dependencies

#57

Nice write-up, I look forward to seeing how Strawberry progresses. I keep a list of JS front end frameworks where no build step is required at https://unsuckjs.com/ . I'll add this there (and a few of the others mentioned in the comments here).

Would you also add these js library to the list? They don't require build step as well. https://github.com/beenotung/html-template-lite https://github.com/beenotung/data-template https://github.com/beenotung/dom-proxy

I added `dom-proxy` because that looked like the closest to a complete solution from a quick skim. Let me know if you want to swap for another one, though.

Re: Building a front end framework – Reactivity, composability with no dependencies

#58
post #5

This 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.

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] https://news.ycombinator.com/item?id=34828992

Re: Building a front end framework – Reactivity, composability with no dependencies

#59
post #6

Enjoy 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.

Thanks for pointing that out. Yes had rewritten it a will need to use a different event to enable the button if there is an update in the input field.

Re: Building a front end framework – Reactivity, composability with no dependencies

#60
post #6

Enjoy 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…

I made a similar library [1] using data-* attributes. It also supports nesting, looping and conditions. For event handling, I use function in object (a.k.a. method) while you support writing them inline. Your way to support inline logic in the text and style is interesting. [1] https://github.com/beenotung/data-template

Very cool, it seems we almost came up with the same approach of components/templates. In your framework, it is referenced with a data-template attribute. In Reken, I use a data-component attribute.

One of the design goals for Reken was to not have to context-switch while coding, to not lose my train of thought (Guess my short-term memory is limited). Hence try to add everything inline in the HTML file. Also I'm working on a tailwind-like css inlining framework (compatible with Reken). Together these give me dynamic DOM and styling inline.

Post reply on HN