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

Don't animate height

granola.ai

Post reply on HN
Print view View original

261–270 of 276 posts

Re: Don't animate height

#261

Post by cpmsmith »

jaapz wrote: post #228
bartread wrote: post #184

Earlier quoted context omitted.

Well, and especially because the “fixed” version is still - if I’ve read correctly - consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor. How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case. The acceptable range would be something like 0 -…

Couldn't they just have used an animated gif or png, the amount of CPU used probably wouldn't even be measurable

You might be surprised at the CPU usage of rendering a GIF. I'm not sure why, but I've previously noticed Slack takes noticeably more CPU when there's an animated emoji on screen.

Re: Don't animate height

#262

Post by valenterry »

ulrikrasmussen wrote: post #227
valenterry wrote: post #187

Earlier quoted context omitted.

That's very very sad. Animations can make UX much better when used correctly.

I disagree. The first thing I do on a new phone is to disable all animations. It makes the phone feel so much faster.

I'm doing something similar. I set them all to 2x the speed. That is much better than disabling them imo.

Re: Don't animate height

#263

Post by valenterry »

gf000 wrote: post #242
adastra22 wrote: post #224

Earlier quoted context omitted.

…how? How do they improve the user experience, at all?

Absolutely, without question. Do you think that humans, who evolved in a physical word where basically everything happens in an incremental way don't extract valuable information from in-flight state? Also, as an example just try to use a window manager that just switches instantly to a new desktop, vs a very short animation. I find the former easily disorienting, and it is even more so when you have a more direct ge…

This is what I meant.

Re: Don't animate height

#264

Post by ajkjk »

lmm wrote: post #206
ajkjk wrote: post #186

Earlier quoted context omitted.

Well I don't know how dartium did it really, but it seems to me like "add a new website implementation language to Chromium" would be a tutorial on Chrome/Chromium's home page. Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS. As far as the actual solution to try for, table stakes is a native implementation of something that looks like React (…

> Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS. What would be the use of that? It would help people who want to make prototypes of a different web with no hope of it ever getting adopted, but that's not a huge market. > table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch) Like…

> What would be the use of that?

So people can experiment with it. Creating a good place to experiment is the best way to make lots of good ideas happen. If 10000s of people can play with ideas instead of the 10 groups with enough time and energy and expertise, you get a much richer exploration of the space. Heck if it was easy I'd be doing it right now.

> Like a component layer?

I'm not aware of anyone creating a component layer that is even passable for abstraction compared to React's programming paradigm. Usually because they stay imperative-first when all signs seem to point to declarative-first being the more scalable model.

> how would you avoid the problems of those?

Umm... they're terrible, so I would just not copy them? Look at XUL for seconds and try not to vomit. WebComponents adds abstraction of HTML in Javascript, rather than in HTML / declaratively, which is obviously never going to work as a foundational technology. It is far too imperative-first. I would start by copying React... but then doing everything differently because most of React's design is forced by being implemented in JS and having to work around CSS being quirky. The greenfield version would do a much better job.

Re: Don't animate height

#265

Post by vanviegen »

wizzwizz4 wrote: post #258
gf000 wrote: post #241

Earlier quoted context omitted.

There are full on CAD apps nowadays on the web. Also, this "looking down" on such a huge group of people is pretty questionable behavior.

There were full-on CAD packages for 133MHz Pentiums.

Yes, and they had perhaps 1% of the features you'd expect these days. Though of course, they were the important 1%..

Re: Don't animate height

#266

Post by troupo »

RumourRider wrote: post #256
troupo wrote: post #255

Earlier quoted context omitted.

> You are being disingenuous. I can always use some hyper specific example These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, " using 60% CPU and 25% GPU on [a] M2 MacBook " How is 2D graphics programming helping there? The article goes on to describe, correctly, layout properties ("The W3C spec is full of these!"), paint properties ("th…

> These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook". No we are not. Someone asked about how one learns some techniques that the OP mentioned (that were simpler than the ones given in the article). I gave some general advice on how one should think about what is happening and some general adv…

> No we are not.

Yes. Yes we are literally discussing this under an article whose introduction literally says what I quoted.

> Someone asked about how one learns some techniques that the OP mentioned

Yes, and the techniques OP mentioned literally cannot be learned from 2D graphics because nowhere in 2D graphics are you going "ah yes, to fix 60% CPU utilization for a primitive animation, you need to apply this awkward workaround that will tell the browser not to reflow the page".

Edit: and this particular technique is only applicable to this specific property for reasons that do not exist anywhere else, except in the browsers.

> wait a minute, that is kinda like this thing I did in SDL 1.2 in university

Well, it's not. Just because it kinda somewhat looks like something different doesn't make it so. Hence my question in this comment: https://news.ycombinator.com/item?id=44658482

Because those are not hyper specific, no matter how much you pretend they are

Re: Don't animate height

#267

Post by RumourRider »

troupo wrote: post #266
RumourRider wrote: post #256

Earlier quoted context omitted.

> These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook". No we are not. Someone asked about how one learns some techniques that the OP mentioned (that were simpler than the ones given in the article). I gave some general advice on how one should think about what is happening and some general adv…

> No we are not. Yes. Yes we are literally discussing this under an article whose introduction literally says what I quoted. > Someone asked about how one learns some techniques that the OP mentioned Yes, and the techniques OP mentioned literally cannot be learned from 2D graphics because nowhere in 2D graphics are you going "ah yes, to fix 60% CPU utilization for a primitive animation, you need to apply this awkward…

[dead]

Re: Don't animate height

#268

Post by ajsnigrutin »

gf000 wrote: post #241
ajsnigrutin wrote: post #226

Earlier quoted context omitted.

MS word on a 133mhz pentium and 16mb of ram needed less than 5s to start. Websites don't need that much resources and should be optimized.... if somehow web developers could read, maybe they'd start doing that.

There are full on CAD apps nowadays on the web. Also, this "looking down" on such a huge group of people is pretty questionable behavior.

There were those apps on pentium 133mhz era computers too, even started in faster tha 5 seconds.

For 99% of the people, word 97 was good enough then and is still good enough now to do whatever they need. They can literally still use it today. (yes yes, docx compatibility, i'm just making an example).

Web stuff is one of the few things where the amount of useful data on an eg. weather report site (webmail, news site, bus timetable site,...) hasn't changed, the cpu requirements have gone way way higher for no useful reason (except to serve more ads), and the users can't use the "old versio" of the site anymore. It's literally gigabytes of ram and multiple seconds of 100% cpu usage to service 5kB of article text and a 50kB article photo.

Re: Don't animate height

#269

Post by notatoad »

socalgal2 wrote: post #166
notatoad wrote: post #142

Earlier quoted context omitted.

not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes. the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.

I don't think it would be different for any other system. Trying to make a piece of computer software that is completely responsive to big displays, small displays, touch screens, mice, etc is just a ton of work and a ton of small details you can't easily learn until you need to learn them.

yes. i don't mean to unfairly criticize the web as a platform, i just know it's warts because it's the platform i work on.

my criticism is reserved for the concept of "first principles", as if there should be a cohesive and simple set of rules that you can build up all the knowledge you need from. that's just not really how any complicated system works: building a comprehensive understanding of a complicated system takes a lot of work and a lot of time.

Re: Don't animate height

#270

Post by troupo »

socalgal2 wrote: post #166
notatoad wrote: post #142

Earlier quoted context omitted.

not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes. the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.

I don't think it would be different for any other system. Trying to make a piece of computer software that is completely responsive to big displays, small displays, touch screens, mice, etc is just a ton of work and a ton of small details you can't easily learn until you need to learn them.

It's not "completely responsive". And literally every other GUI is just as responsive when coded for those screens.

Have you never resized a window on a desktop OS?

Post reply on HN