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.
Idle work showing up in flamecharts is usually the thing to be cautious of.
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 step.
The "JellyEngine" instead of just calculating the jelly animation on pointer events is recalculating for every active component on the page every frame.
This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.
I’ve been on Tysabri for 3 years. I think anyone looking at this problem should just at the network meta analysis of outcomes from DMTs. You can think through each options risk profile, and then make a reasonable choice for your preferences. consensus.app is a good starting place for evaluating the research quickly.
if anyone needs to discuss i’d also be happy to share my experiences if you reach out.
It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.
The main problem with this approach is that there’s a normal distribution of quality of contribution for OS but the community of OS users only benefits from the highest quality contribution. This is normally best achieved by the continuous contribution of the original author(s) who created or maintain the project, as they were the ones capable of designing a project complete and correct enough to achieve traction.
Most projects will actually deteriorate in overall quality if they accept average level contributors work, and certainly face harsh consequences if they accept below average contributions. Highly competent contributors demand higher salaries for their work which can’t be met by the limited funds available to OS, hence most high quality work comes from company sponsored OS or from people who have other means of financing their lifestyle outside of open source.
Roundabouts always make think about the two parts of problem optimization, determining your objective function then optimizing. Many classical failure states for real world problems seem to involve having an OF that is incorrect then prematurely optimizing. Think of the rich guy who wants “love at all costs” and then pursues women with expensive gifts and fancy restaurants. You may achieve your aim but perhaps you won’t get what you want.
I think the same is true of roundabouts. One part of the experience that seems almost never to be mentioned is the experience for a passenger when encountering a series of roundabouts. Let’s say you had some bad oysters and are resting your head in the back of the car on a pillow and praying you can make it home before you upchuck your dinner. Perhaps some road engineer decided to put 5 or so roundabouts consecutively to “optimize traffic flow” then somewhere around spin number 3 you lose your stomach on the backseat. Perhaps the trip was not “optimal” for you.
The Design of Design was one of the primary inspirations for my open source project Semantic UI.
"[Progressive truthfulness] is perhaps a better way to build models of physical objects...Start with a model that is fully detailed but only resembles what is wanted. Then, one adjusts one attribute after another, bringing the result ever closer to the mental vision of the new creation, or to the real properties of a real-world object
...Starting with exemplars that themselves have consistency of style ensures that such consistency is the designer's to lose."
its cost $100/month for 10 years to run but i keep it up because a lot of schools use it to help set up their shared computers and i couldn’t ever have the heart to shut it down.
Once you set it up you can also run it entirely offline using app manifests from myfav.es/fast if you don’t like the idea of your new tab experience being slowed down by web requests.
I find this website to be a fairly amusing example of how marketing co-opts real, generally easily expressible ideas to be an amalgamation of highly targeted jargon and pointed funnels for personal information collection.
Generally any well intentioned person who worked on an idea like this would be delighted to share what their product does specifically and clearly - unashamed screenshots of interesting visualizations (maybe half cooked), telling descriptions of specific numbers being crunched and their utility as predictive indicators of project success, verified with statistical certainty.
Sadly this kind of naive, honest approach is very regularly usurped by the machiavellian machinery of the professional art of convincing others to buy things, which is narrative focused and story driven with very little concrete substance.
Not blaming the author here, I understand the motivations at work and sympathize with them, but still sometimes find myself dumbfounded by the results.
I think the confusing thing here is the use of the term “design token” to mean variables/constants used for css theming.
I think they need this jargon to make it seem like something more novel than the well established practice of storing css constants as theming variables—something OSS UI component libs, or even wordpress, has been doing pretty well for a long time.
I think there’s a general issue with design at startups— the actual products of most design departments are “jpgs”, and so most professional designers are really professional jpgers. This means designers are part of an upfront handoff process and not active participants in feature development.
I think the only recourse is to hire designers who understand how to interact with a UI component framework in code, and have design be a code stubbing process not a jpg producing process.
This does require for your design department to be built upfront to handle this kind of process, good luck trying to retrofit existing design departments codified around “jpg handoffs” to work with an implementation level source of truth.
I think generally current startup hiring discriminates in hiring for post vs pre internet age programmers and that could possibly account for the statistical differences in salary for developers that didn’t spend their entire careers under the current paradigm.
If anyone's interested in reading something along these lines from the literature. One of my professors in college who I greatly admired has written a tremendous amount around PPA (personal project analysis) a framework for interpreting motivation and happiness in relation to your core life projects.
I still think when handled correctly seniority is the best incentive to reward correct decision making. The problem arises in the (quite frequent) circumstance where people who get to positions of power aren’t there because they have the best guidance / deepest expertise. This is an issue with implementation, not a fault of heirarchy.
I think I’m the domain of the article, design, the guy who is creative director / dept head generally is a good candidate for arbitrating a design or product dispute in companies that promote leaders effectively.
In situations with clear org structure the final decision between product disagreements can always be handled by the chain of command. When two product people disagree on a feature, the one higher up the org chart can then make the final call.
Feelings are saved because roles are clearly defined, and those with greater product knowledge have the authority they need to "make the call", making the product better overall.
For those stuck lower in the org chart, they can rest assured knowing the more good ideas they contribute, the quicker they will rise up the ranks in decision-making authority. When job mobility is also meritocratic and has efficient review processes, those middle managers should be correctly rewarded or punished for making good or bad calls.
The problem arises for confrontation more frequently in startups because org-structure is often very loose. It's seen as "undemocratic" to force an issue because of seniority, even if someone may have more experience in a topic. Startups generally the traditional business hierarchy as being inefficient for decision making, because many institutions also fail to properly reward decision-making, or punish bad managers.
When Eric is describing having to wake up at 5 am and work weekends to make Code Sponsor work even with the proceeds of 60% of all OS projects his ad network funded, it should be pretty clear the other 40% divided among many OS coders couldn’t be enough for their project’s development to feel sustainable.
As much as I commend Eric on trying to find a solution to OS maintainability, I think he actually just reinvented something already available to OS developers, a niche tasteful ad network, I.e carbon ads <https://carbonads.net> something which many OS projects with a large enough audience already include to support development.
http://www.semantic-ui.com