jsf01

Off the top of my head, things I use most beyond L/R split include:

1. Workspaces. Not at all unique to i3 but I’ve kept mine themed and automatically load certain apps into the same workspaces—all things i3 makes easy to do.

2. Floating scratchpad for media player. Nice to have my music controls always accessible but only visible when I unhide them.

3. Vertical split beneath my editor with a terminal. Just my personal preference, but I typically have L/R with code/browser and then split the code half vertically.

Being able to move windows across displays and workspaces quickly are other pluses, but again, not at all i3 exclusive.

In addition, google trends limited to China doesn’t match their claim.

Have you taken an antibody test? Been sick since you got over that illness in 2019? You could help add a datapoint to this Fall 2019 mystery.

Not as simple as just downloading an extension, but one could use a PiHole or similar network-wide ad blocking.

Really great idea! Just a small note though your pricing page doesn’t work on a mobile device. It just renders a bunch of checkmarks without context

What stops me from signing my own deepfaked video and putting that on the blockchain?

All these weird prices ending in 7–Is that something you arrived at by A/B testing or something else? Just from first impressions seeing $397 made me notice the prices much more than, say, $399 or $400.

The answer is usually to use SVG. You see this in most maps and charts with clickable or interactive areas. For cases where you need a raster image to have clickable regions, like showing plots of land or property boundaries on a real estate website, you might see a mix of a raster image below a semitransparent SVG overlay or just a <canvas> element instead, which would have to manually reimplement handling clicks and hover events on the various regions.

20% over 3 years—ouch.

Yes. One of the costs of having a low barrier to entry for publishing is that the quality is generally lower. NPM still hosts tons of very well written code, but you have to sift through quite a lot of noise to find it.

I like it. If it’s intentional and kind of cheeky the way I interpreted it then I see no issue. It’s funnier and less bland than some strictly technical alternative. If it’s just an innocent call to action and just coincidentally happened to be a nod to the campaign slogan then that’s fine, too. There’s really nothing worth pointing out here.

The parsing cost for 100+ kB of JavaScript is not negligible. Sure maybe the transfer over the network is comparable to an image file, but you can’t stop measuring there. And to claim “Lightweight” on the homepage for something that should be tiny when uncompressed is a bit of a stretch—lightweight compared to what?

It was disappointing to see that despite multiple months to do so, not one of the five packages implemented a patch before the public disclosure.

Apparently there’s an app you can install (if you are running Windows) through the Microsoft store that demos each component. Why wouldn’t they just throw up some screen shots? Beats me.

Is there a way to see a preview of each UI component?

Because the only update occurring is the changing of text in an input. Yet due to how React works it’s diffing a much larger tree.

That’s a good point. There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate while mithril’s tends to advise against those methods. The blog post behind this thread is a prime example.

React is far greater than 2x as slow on some metrics, like boot time, but the newer versions actually aren’t as bad as the pre-fiber versions that those benchmarks are based on for DOM updates. For boot up time React is still about 5x worse than Mithril, but on create & update benchmarks they’re now at least in the same ballpark.

https://krausest.github.io/js-framework-benchmark/current.ht...

Most web developers should be more concerned with performance than they are. In the wild, on a fairly recent MacBook Pro, I frequently run into sites where I deal with 100ms+ input lag. And every time I check, it’s always React (sometimes Angular) under the hood. These are sites with great dev teams too. Stripe, Airbnb, Squarespace to name a few, suffer from severe performance problems on modern hardware. And those issues stem more from the diffing and reconciling stages than the actual DOM itself, whose updates are minimal for things like entering text into an input.

So true. This reminds me of one of my favorite tidbits from another vdom framework’s documentation, in which using the equivalent of shouldComponentUpdate is generally considered to be an antipattern. Whereas in React, it seems idiomatic to just memoize and throw in shouldComponentUpdate wherever you can as much as you can.

https://mithril.js.org/lifecycle-methods.html#avoid-prematur...

The person responsible for paying for the dispute. The user who goes to create an account on stripe.com to allow them to sell stuff on their site.

The most effective anti-fraud solution would be a major privacy violation just by the nature of anti-fraud itself. So, since the stripe user is the one being charged for disputes anyway, giving them control over how much more privacy to give up in exchange for better protection is completely obvious. Even if the default is to be extremely pervasive as Stripe’s anti-fraud measures are now, the option to reduce that tracking is a must.

I am excited by this from what all the docs say but every one of the demos is either broken on my iPhone or so extremely slow to load that I am not able to demo it.

Does anyone have a non-paywalled mirror?

This is definitely not smooth on iOS, on a brand new iPhone that’s arguably way faster than whatever system played the original DVD screensaver.

On a technical note, not that there’s much you can do about this, but because you’re reading clientWidth and clientHeight each frame, you’re forcing reflow. A performant implementation would probably require avoiding the DOM altogether within the draw loop, so that would mean using canvas/webgl.

Do you know where to find docs on what svelte actually compiles to? I’m curious how they store/reference/update dom nodes in the compiler output.

There are some fairly standard vdom benchmarks you could implement instead.

https://github.com/krausest/js-framework-benchmark https://localvoid.github.io/uibench/

Or even just something following mithril’s own benchmark suite: https://github.com/MithrilJS/mithril.js/blob/next/performanc...

Interesting. Is that based on your experience or is there somewhere I can read more on that trend?

I’d be interested to read a deep technical post-mortem like those which have become fairly standard among other big tech companies. Hoping Robinhood does the right thing here.

So this is built on Slate—what does it bring to the table that you can’t do with Slate out of the box?