Comments URL: https://news.ycombinator.com/item?id=42439999

Points: 1

# Comments: 0

The ring's source code in particular had to be transcribed from an actual shader I made (https://www.shadertoy.com/view/msd3R2). I didn't have the patience to write it directly in CSS. It's neither the right semantic nor the medium for it (which does make you wonder what CSS' medium was supposed to be).

Out of curiosity, I've transcribed that ring, which runs at <1 fps with pure CSS, into a JS version with requestionAnimationFrame + setting the background color (https://github.com/chenglou/pure-css-shaders-art/blob/master...).

Perhaps unsurprisingly, it runs at full 120fps on a decent laptop (it's just 21*21 JS style setting really). I've tried to make a half-JS, half-CSS version, and the speed is somewhere in-between. Basically, CSS variables are _extremely_ slow across all browsers, and I don't believe I've hit some particular edge-case. They're not used idiomatically here, but still, we shouldn't hit this drastic of slowdowns when updating 441 styles. They're also pretty hard to read the moment the calculation isn't some trivial basic arithmetics; and even then...

The true shader version runs at basically infinite fps =)

Comments URL: https://news.ycombinator.com/item?id=37620949

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=35297215

Points: 9

# Comments: 3

Basically, performance doesn't compose well under current paradigms, and you can see Casey's methods as starting from the assumption of wanting to preserve performance (the cycles count is just an example, although it might not appeal to some crowds), and working backward toward a paradigm.

There was a good quote that programming should be more like physics than math.

Generally, Casey seems to preach holistic thinking, finding the right mental model and just write the most straightforward code (which is harder than it looks; people get distracted in the gigantic state space of solutions all the time). However this requires 1. a small team of 2. good engineers. Folks argue that this isn't always feasible, which is true, but the point of these presentations is to spread the coding patterns & knowledge to train the next gen of engineers to be more aware of these issues and work toward said smaller team & better engineers direction, knowing that we might never reach it. Most modern patterns (and org structures) don't incentivize these 2 qualities.

Comments URL: https://news.ycombinator.com/item?id=31717765

Points: 1

# Comments: 0

I manage a web UI programming language in my free time, and the juxtaposition of folks claiming FP ergonomics benefits, then upon my request, showing a static, interaction-less end result whose improved version would obviate their pristine architecture, is pretty staggering. The typical defense is "hey we're not designers" but if you zoom out a bit you realize the whole environment doesn't foster engineers to care about design concerns anymore (barring a niche but valuable vertical of optimizing for payload size). This in turn puts pressure back onto designers who come to expect less and less of what they care about on the web.

Just the other day a newcomer shipped an animated row transition after fighting her framework for 3 weeks. The designer was delighted, but the manager didn't even get the point because he matured in whichever era of JS framework that de-emphasized acquiring taste in interactions.

I myself come from a Flash background, so rather than seeing an upward trend, I see a decline in UX concerns, followed by an incline of devops-related concerns in UI frameworks (accompanied by HN comments saying that in both cases the web should have stayed as a document format, only to end up with an awkward mix of document + app architecture their desktop apps through Electron anyway).

If I were to categorize these "eras", I'd rather take the perspective of wondering at which point, and why, framework process ended up more important than the product. Heck, a similar thing is happening on native too, unfortunately. Where did all the interaction designers go?

Maybe AR would nudge more folks to learn and focus on rendering, gestures, transitions, framerate, intent and the rest.

Comments URL: https://news.ycombinator.com/item?id=30401284

Points: 11

# Comments: 4

Although constraint declaration is orthogonal to data-oriented development, I'd say that the philosophy of using generic constraint solvers (or other overly generalized CS ideas) goes against the spirit of DOD, which is to "just simply do the work". It is after all reacting against object-orientation (and even modern FP) which tended to think too much in the abstract and worrying too much about some form of taxonomy, as opposed to coding against plain data.

Static analysis-wise (which is what most of the blog post's about), things are basically the same. The tradeoffs are mostly just in terms of readability. I used to be ambivalent about this myself, but looking at the growing body of GitHub TypeScript code with mountains of imports automated by VSCode, imo we've landed on a decent enough design space.

Compare that to e.g. Swift's iteration, with corners of undefined behaviors, potential allocations, and a collection types hierarchy that feels more like doing taxonomy than just looping.

Though to be fair, Jai's loop is rather intense in its usage of a macro system's features.

Related: Common Lisp loop macro: http://www.ai.sri.com/pkarp/loop.html

Comments URL: https://news.ycombinator.com/item?id=29820438

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=29455923

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=29402436

Points: 67

# Comments: 27

Comments URL: https://news.ycombinator.com/item?id=29089265

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=28966121

Points: 1

# Comments: 0