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
Building a front end framework – Reactivity, composability with no dependencies
51–60 of 80 posts
Re: Building a front end framework – Reactivity, composability with no dependencies
#52Please 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.
Re: Building a front end framework – Reactivity, composability with no dependencies
#53Earlier 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.
Re: Building a front end framework – Reactivity, composability with no dependencies
#54Earlier 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.
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
#55New 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…
Re: Building a front end framework – Reactivity, composability with no dependencies
#56Nice 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.
Re: Building a front end framework – Reactivity, composability with no dependencies
#57Nice 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
Re: Building a front end framework – Reactivity, composability with no dependencies
#58This 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).
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?
Re: Building a front end framework – Reactivity, composability with no dependencies
#59Enjoy 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.
Re: Building a front end framework – Reactivity, composability with no dependencies
#60Enjoy 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
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.