jlukic

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.

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.

This shares a lot of similarities to what I’m doing with new version of Semantic UI.

Components - https://next.semantic-ui.com/components

Templating - https://next.semantic-ui.com/templates

Signals - https://next.semantic-ui.com/reactivity

DOM - https://next.semantic-ui.com/query

API Refs - https://next.semantic-ui.com/api

Working on a new version of semantic ui for authoring ui with web components and signals based reactivity without a compilation step.

https://next.semantic-ui.com/

Has Tailwind support out of the box, just had to mod oxide to get non threaded wasm support in the browser

https://next.semantic-ui.com/examples/tailwind

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

Frederick Brooks - The Design of Design

I also run a customizable start page http://myfav.es

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.

Nice vignette, thanks for sharing this.

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.

http://www.brianrlittle.com/articles/%EF%BF%BCpersonal-proje...

I find this to be a very helpful framework for engaging in a more scientifically rigorous discussions around happiness and life satisfaction.

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.

Incredible work, by an incredible programmer.

Just my two cents here.

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.

I’ve read through your pdf docs explaining wolkenkits approach to CQRS.

I think most of the value you’re describing through correctly modeling behavior to language is only important at the level with which most teams deal with data—and this isn’t necessarily the DB level. Just like our brain may use (relatively crude) bio mechanical processes to encode & recall information, yet at a higher level of abstraction relies on the flexibility of natural language, to codify and transmit meaning between idea storage systems (people), I think a similar process is at place with programming. Let the low level stuff stay low level and optimize for performance/throughout and not meaning, then in the higher order aspects of code make sure the abstractions that are most used by teams map data to constructs which humans use to communicate meaning.

I think this approach can be found in any framework, including meteor through effective abstractions, as nearly all frameworks give you the necessary mechanisms to map data. I think the issue with ineffective language systems is mostly the same reason people hate poetry. Most people have a difficult time adequately mapping ideas to language, because it is extremely difficult to do it correctly to the satisfaction of others.

These utility functions and shims are "per" component. This means that functions like extend will be repeated many times in different idiosyncratic code across app.

Imagine your app uses, modals, dropdowns, multiselects, search autocompletes, sliders, rich text areas etc. Instead of having one cached utility library upfront you have many hidden utility libraries scattered around each component, which makes it difficult to say clearly that jQuery is always larger.

The other issue is maintainability. When you're working with third party components, hot-fixing an OS library can be fairly daunting if you need to also learn their own internal class structure, selector helpers, dom manip functions. Doing this in jQuery, it's fairly easy to fork the codebase and plop in a .clone() or .append() to fix a stale issue.

Wanted to confirm same issue for my .io domains. This has gotten a lot of people up this morning.

Author here.

Fixed the scroll issue in the docs. Should be glorious normal iOS scroll.

Author of SUI here again.

Semantic is based on the idea that describing physicality (the function of html/css) is a task natural language is acutely optimized for, while describing the implementation of behavior ("cooking recipes", or the vast majority of programming implementation) is best served by programming languages.

Part of how natural language optimizes for transmitting meaning is by reducing ideal forms of concepts to words based on the exact amount of specificity for conveying meaning between humans. I.e. "horse" instead of "quadrupedal mammal that has a heart and has eyes and has a tongue..." etc.

These 'units of optimized human idea transmission' (read words) are then clarified using a system of modifiers that take care of removing just enough ambiguity that the idea is communicated effectively. "The kindly, gentle lion", "The angry, hungry lion".

The modifiers themselves carry no absolute meaning. A "large ant" may be smaller than a "small planet", but we understand them -- in context -- of the nouns.

Language is littered with other interesting features like this that are designed particularly for this task of describing physicality. Most of which are absent from programmatic implementations of 'languages for describing physicality' like HTML/CSS.

Other key examples of useful cognitive optimization: Plurality, "Three large red buttons" vs "Large red button, large red button"; significant word order, "left floated right aligned column" vs "right floated left aligned" column.

I think the main drawback with using a natural language approach is that the implementation has to be bullet proof. Although everyone uses language, we never have to implement systems of interpreting language from phoneme to neuronal pathway. So even though the benefits are clear, the path forward in mapping language to systems of programmatic physicality isn't exactly straightforward.

For people who are curious about theming here is classic GitHub done entirely in Semantic UI. http://semantic-org.github.io/example-github/

(Click the small paint icon in the top menu to swap themes to see in native SUI)

I did a meteor dev night where I talked about some of the ideas behind Semantic UI, which might clear up some of the linguistic origins for the library and it's ideas about language: https://www.youtube.com/watch?v=86PbLfUyFtA

And if anyone wants to dig really deep, there are a few podcasts as well https://changelog.com/podcast/106 https://changelog.com/podcast/164