Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

18alan.space

Post reply on HN
Print view View original

21–30 of 80 posts

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

#21

Post by luisgvv »

klysm wrote: 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

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

#22

Post by _heimdall »

ttfkam wrote: post #20

They 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.…

Kind of bending definitions to say svelte doesn't have any dependencies once compiled. Svelte itself is a dependency, and though complex and bundled there are svelte utilities included in the app that aren't code directly written by the user. Anecdotally, if also be very interested to see any example of a production Svelte project that doesn't pull in any other dependencies.

The article also calls out no build step, though it's not in the title. That's an important factor for the kind of project that isn't updated regularly and needs to work without any fuss after a year or two of going stale.

I'm a big fan of svelte by the way, been using it since pre-release 2.0 and still reach for it whenever I need a more complex state management or don't have the time to roll my own animation trigger utilities.

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

#23

Post by muspimerol »

datadeft wrote: post #8

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

I think the common argument is "complex interactivity". If you have sufficiently complex custom client-side interactivity (e.g. sending, receiving, manipulating and displaying data in the DOM without constantly reloading the page) then something like React or Vue is much easier and more maintainable than a bunch of custom JS. Logic for mutating and displaying data can also live on the backend and use SSR, but it has to live somewhere. I think people like SPAs because you can draw a convenient boundary at the server level by exposing a JSON API, and folks working in HTML, CSS and JS like the component model offered by frontend frameworks (I know I do).

There's also something to be said for consistency. When I walk into a React or Vue app, I can figure out what's going on and build on top of it quickly. Even if they are using a mish-mash of libraries (as JS apps do) the majority of the time you will see similar libraries and patterns used.

All that said, there are many monstrosities built upon SPA frameworks with poor performance that would likely provide better user experience if they were using SSR. But there were also many SSR monstrosities built before SPAs were in vogue.

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

#24

Post by lelanthran »

hbroek wrote: 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.

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

#25

Post by austin-cheney »

klysm wrote: 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

Depends on the definition of simplicity. People say they want simple, but then really want easy. The most easy is always somebody doing the work for you. I got tired of hearing people mention easy when really they probably mean some combination of fearful and/or lazy, so I chose to define easiness:

https://github.com/prettydiff/wisdom/blob/master/Easiness.md

If developers really wanted simplicity or to be done with work faster they would just learn the primitives of their environment: DOM, functions, and events. Most of the frameworks have APIs that are huge, so clearly simplicity isn't what's wanted.

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

#26

Post by aabbcc1241 »

I'm experiencing the trade off between simplicity and expressiveness for a lightweight frontend library that doesn't involve VDOM.

On one hand, a library [1] can be very concise (update dom from object, with looping and nesting supported).

On another hand, a library [2] can be very flexible and reactive (update dom from dom events).

However, when double-binding (a.k.a. bi-directional binding) is required (update dom from object and update object from dom), it seems more complex than I would consider it lightweight.

When double-binding is preferred, I'd rather go for angular / vue. Still exploring alternatives.

[1] https://github.com/beenotung/data-template

[2] https://github.com/beenotung/dom-proxy

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

#27

Post by ttfkam »

_heimdall wrote: post #22
ttfkam wrote: post #20

They 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.…

Kind of bending definitions to say svelte doesn't have any dependencies once compiled. Svelte itself is a dependency, and though complex and bundled there are svelte utilities included in the app that aren't code directly written by the user. Anecdotally, if also be very interested to see any example of a production Svelte project that doesn't pull in any other dependencies. The article also calls out no build step,…

Fair points.

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

#28

Post by joncfoo »

grncdr wrote: post #2

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

This is really neat! I'm going to take it for a spin in a simple CRUD internal app.

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

#29

Post by adparadox »

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

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

#30

Post by imbnwa »

As someone who started out in this profession in their early 30s, it was made clear very quickly, both by observation and shared wisdom, that it was completely possible to go one's entire career never getting below the level of gluing business code together with the adhesive of some framework, i.e. never learning how to design a system or think from the 'bottom' of a solution.

While its arguably more accessible than ever, you can quickly find yourself swimming in a shallow pool if you're not careful where your first job is, unless you have the free time and comportment to swim towards the deeper end on your own. And the larger magnitude that this occurs at, the greater the stranglehold of most devs to some well-funded framework and tooling.

So I applaud reminders like this that ask to just take a step back from time-to-time and maybe provide ourselves a new opportunity before reaching for $BIG_FRAMEWORK when the project is a few views w/ some buttons and an input on them. There has to be some balance between the utter pragmatism and curiosity and exploration that builds skills to have a healthy demo of devs.

I routinely see this second-hand classist complaint about 'JavaScript devs ruining software' (particularly w/ Electron in hand, even though the most used Electron apps are probably worked on by high-tier devs) but really the source of that concern is the market desiring that devs be more or less replaceable for the most part and the skillsets follow that. You can't break that without some disruption to the Framework-Industrial Complex.

Post reply on HN