Live data from Hacker News

Jelly UI: Soft-body physics for native HTML form controls

jelly-ui.com

121–130 of 209 posts

Re: Jelly UI: Soft-body physics for native HTML form controls

#121

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

People have spoken, so I removed the scroll snapping.

Re: Jelly UI: Soft-body physics for native HTML form controls

#123

Earlier quoted context omitted.

A website shouldn't be pinning CPU or GPU. When people run a game they expect some sort of battery drain. People don't expect that some websites will thrash your CPU/GPU like a game.

> A website shouldn't be pinning CPU or GPU. That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work. This page, however, has an animated SVG and moving DOM elements in the header which consume far more resources than the widgets it is trying to showcase. Compare usage before and after deleting the header element (`section.hero`) in the inspector to see for…

> > A website shouldn't be pinning CPU or GPU.

> That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work.

Your comment doesn't say this at all:

> > This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.

> It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.

Am I missing something? Are you referring to some other part of the thread?

Re: Jelly UI: Soft-body physics for native HTML form controls

#124

If I were younger I would love this. nowadays I spend most of the time tweaking websites to remove this stuff using local stylesheets...or using dark + read mode... how times have changed.

I flip back and forth every year or so between wanting more fun in my software, and wanting it to get the hell out of my way.

"There's a time and place for everything, but not now!"

I think now that llms make it super easy to add anything that its important not to add everything.

Re: Jelly UI: Soft-body physics for native HTML form controls

#125
post #71
post #38

Saw the window was a bit laggy so thought I'd delve deeper to figure out what was going on. This lib runs a a RAF animation loop every 8ms across every component on the page that causes the entire document to repaint. The comment above appears of the AI generated sort: // One shared animation frame: step every live component, park when idle. // The delta is capped so a background-tab pause never becomes one giant ste…

> This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'. It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.

> Yes my car is running all night while it stands in front of my house, but it's not really a waste of resources or a nuisance because generators do the same thing.

Re: Jelly UI: Soft-body physics for native HTML form controls

#126

Earlier quoted context omitted.

> Visiting a web page does not have that action-reaction causality in people’s minds It does in my mind. I fully expect visiting any of reddit.com, github.com, notion.so, or meet.google.com to have the chance to pin a cpu core at 100% for as long as the site is open. At this point, I expect the average webpage to use more CPU than any of the video games I play. The only reason I had to upgrade to my current machine i…

As a web developer, I am not included in the perception difference I describe. I am also 0.000001% and not a representative sample of People As A Whole Or Even As A Majority Or Significant Fraction. So while my personal awareness is akin to yours, extrapolating from that towards the masses is a dead end exercise. CPU bound games examples: Chess, Go, Final Fantasy XIV, Elite Dangerous, and any competent Civilization /…

If the geneva convention didn't ban torture, I'd say that web-developers should be forced to actually try and use the apps they develop.

The websites I mentioned use more cpu and memory than most games in Civilization the series, which are largely competently developed. My previous laptop could play civ 5 at a higher framerate than it could scroll github diffs or notion pages. Civ 5 handled full-speed keyboard input, while notion doesn't let me input text at my roughly 100 wpm typing speed.

I agree that we shouldn't be expecting users to figure out how to close the right tab, however I'm reporting the way things currently are, which is that webpages are poorly optimized messes.

Re: Jelly UI: Soft-body physics for native HTML form controls

#127
It's cute. But the reaction time on some of the controls is so awful. If I click and drag the slider control back and forth, it lags behind the mouse cursor substantially. It should feel like it's stuck to the mouse cursor like glue.

By contrast, most of the other controls do seem to stick to the cursor, such as jelly-resizable.

Also, the "Placeholder" control seems to fail to actually make the placeholder disappear when clicked in.

Re: Jelly UI: Soft-body physics for native HTML form controls

#128

Earlier quoted context omitted.

> A website shouldn't be pinning CPU or GPU. That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work. This page, however, has an animated SVG and moving DOM elements in the header which consume far more resources than the widgets it is trying to showcase. Compare usage before and after deleting the header element (`section.hero`) in the inspector to see for…

> > A website shouldn't be pinning CPU or GPU. > That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work. Your comment doesn't say this at all: > > This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'. > It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limite…

Sorry, I meant to say that it was what I was suggesting. Video games render a lot more than the widgets on that website. Rendering less takes less time, so your `requestAnimationFrame` loop idles longer between executions waiting for vsync, which means your CPU or GPU usage is not pinned.

Re: Jelly UI: Soft-body physics for native HTML form controls

#129
post #103

Earlier quoted context omitted.

Running a performance profile in Chrome doesn't back this up for me, and looking at the loop it looks like it maintains an active `Set ()` of which components to update, and clears them out when they stop moving. Agreed the comments look a bit slop-ish but I don't see anything obviously wrong with its approach, and the core loop is running in microseconds for me when nothing is happening.

Here's the perf profile, just to clarify. Cursor idle, viewport on the button examples. 3ms repaint every 8-11ms. Animation frame points to the code i mentioned. https://postimg.cc/sQpZxxzv The problem isn't doing work on a website, its if you have an idle task that is taking up a significant portion of the frame budget then its easy to have frame drops when you do significant work like clicking, scrolling, browsing.…

That's from Lottie, the animations that play in the header and footer of the page. Shrink your window until they disappear and try again.

Re: Jelly UI: Soft-body physics for native HTML form controls

#130

Meta, but is there a good resource to find these types of HTML UI component frameworks? I have googled and searched but all I get a listicle-style pages that aren't very curated.

https://github.com/topics/design-system

Oh man there are a lot there:

> Here are 5,338 public repositories matching this topic...

Thanks for the link--I didn't know you could search Github by topic.

Post reply on HN