Yet another people denying React Hooks has won...
Building a front end framework – Reactivity, composability with no dependencies
11–20 of 80 posts
Re: Building a front end framework – Reactivity, composability with no dependencies
#12Very thin frameworks can avoid the complexities of React and hooks and useEffect and whatnot. Here's an app written with a 500-line "framework", notice how readable and maintainable it is:
https://github.com/wisercoder/eureka
Re: Building a front end framework – Reactivity, composability with no dependencies
#13Very thin frameworks can avoid the complexities of React and hooks and useEffect and whatnot. Here's an app written with a 500-line "framework", notice how readable and maintainable it is: https://github.com/wisercoder/eureka
Less Framework and more Library it feels like.
Also, wondering if there are other tools for searching code and other internal Corp stuff on external services (GitHub/Lab, Google Drives, etc)
Re: Building a front end framework – Reactivity, composability with no dependencies
#14New 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
Re: Building a front end framework – Reactivity, composability with no dependencies
#15New 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'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"
Re: Building a front end framework – Reactivity, composability with no dependencies
#16New 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 feel like the only things that provide “ leaps in simplicity” as far as web dev goes are basic css frameworks.
Generally they really can save a lot of time / needed structure.
Re: Building a front end framework – Reactivity, composability with no dependencies
#17New 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'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
#18> The second main reason is the ability to define a component and reuse it without having to redefine it every time we need to use it. This is called composability.
Uhm, this isn’t strictly composability. Its reusability. Composability is distinct in that you’re architecting or designing components to be composed with one another. That is, they only know what they need to know and isolate domain. Also, their composition interface is the same as their output interface. A likely outcome is reusable components, but it’s not the goal necessarily.
Re: Building a front end framework – Reactivity, composability with no dependencies
#19Earlier 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.
What are some examples?
Re: Building a front end framework – Reactivity, composability with no dependencies
#20They 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. That's why it wasn't adopted widely and why it will likely never be adopted widely.
The funny thing about stories like these is that once you write the first general use code that isn't based on your specific task, you've created a dependency. Only this dependency isn't improved and maintained by a community or company; its maintenance is handled by you and your team. Maybe you take it on because the benefits outweigh the costs for your team. You improve and refine "just a few functions". Other folks like what you've done and ask to use it. Now they have a dependency on the "no dependencies" framework. Eventually you have to give it a name, and it gets popular.
A few years later, a developer decides they doesn't want any dependencies in their front end code anymore…