161–170 of 205 posts
The blog post mentions that seeking to any point works very well without having to create keyframes, just from the speed of the implementation. It would be great if the progress bar could actually respond to click-and-drag events, to quickly find a specific location.
Earlier quoted context omitted.
What a boring takeaway from this. Beyond the fact that the immutable data structures proposed by Clojure/script tend to perform very well in a lot of "normal" cases (and in a lot of normal web-app workflows your stuff is immutable, like "query then display the result from an API"), at least to me it feels like asciinema is a very good example of a case where you have tougher-than-average performance requirements. Not…
Won't make them slower, anyway. There are often performance bottlenecks you didn't know about, and had blamed on database (or whatever) interaction overhead. It will never feel worthwhile to dig into each candidate, because any payback seems too unlikely. Not having left scope for such bottlenecks means you can be confident they are not there. Re-implementing once is a lot less work than diving into each possible bot…
That's kind of funny in light of the history that certain optimizations in web layout engines were attempted, unsuccessfully, in C++ multiple times and ultimately they invented Rust to make them easier.
It's funny how it starts out with "immutability is really fast and GCs are soo good" and ends up with "rewriting everything in unmanaged code made it 50x faster". Similar how "Ruby and Python interpreters are slow but webapps are IO bound anyway so it doesn't matter" to "how can I get this to handle more than x req/sec, can we get a JIT to speed up our dog slow backend".
Turns out that if you write business logic with abandon, you end up with a lot of business logic.
Personally I wish that Python, Ruby and the ilk all get replaced with Lua, but also that Lua gets a proper `null`.
It's awesome to see performance-oriented projects to find their way to SolidJS( https://www.solidjs.com ). So satisfying to see success stories like this one. Great work.
Wow, I just read about Solid for the first time, and I'm very impressed at the API design. I love how it's actually a fully reactive data flow thing, but it looks and feels like React Hooks. The other reactive/observable-based frameworks I've seen (eg Cycle) very much put the observable streams center piece, and I always felt that was distracting, and that nuances about how the underlying observable stream library wo…
I am confused about why this is a positive.
React Hooks are the reason why I want to stop using React. They are confusing and seemingly magical, compared to lifecycle methods that make a ton of sense. While I agree they can make complex things easier, they are also incredibly easy to get wrong, as they are order dependent.
Reading the Solid landing page, what I see is "Solid takes the most confusing part of React, and runs with it."
Earlier quoted context omitted.
Those are pretty heavy unless it's only a second or two (then why would you need a gif at all?) You'll be further cutting your target audience to the extremely privileged. I've had to suffer with dial-up (3-4 KB/s) until 2009, and with shitty ADSL (15-30 KB/s) until 2013. Many parts of the world are still like that.
I have a here 90 second .gif I made a year ago (demo of a particular Vim syntax highlighting scheme for a commit message format). It contains 930 frames, 10 fps. The resolution is 1200x768. The .gif is 600.0 kilobytes, so the coding density is about 660 bytes per frame. Someone downloading at 3-4KB/s might find the download annoying; on the other hand, it could play back on a 66 MHz 486 DX they found in the dumpster.…
ooh actually, I got banned from the Ars-Technica forums way back in the day for posting a giant 800x600 animated GIF. It took browsers a few minutes to render! People thought I had crashed their browsers, but they just needed to be patient. ;)
I think I had a Duron 700mhz back then, so a 486 would've been turned into toast.
(Or, possibly, IE's GIF code was just really bad at that time! :) )
Earlier quoted context omitted.
Generally in compiler technology, immutability is an important tool in letting compilers reason about and make program transformations. See eg the "single static assignment" intermediate-representation form that is mainstream in low level language compilers. But SSA form isn't as good as having the original program expressed immutably, because you get false or incidental data dependencies if the compiler has to conse…
Talking about parallelization opportunities is a bit pointless when you need 50 cores to match the performance of the single threaded code (in the best case, assuming perfect scaling).
Earlier quoted context omitted.
that's only because js is "stupid" if you have the string "hello" and somewhere else "hello world" you can retain only one copy of "hello" because it's guaranteed it won't change. but js vm it's not smart enough for that.
You're wrong, JS has immutable strings & so VMs use ropes to make mutable usage & slicing fast https://gist.github.com/mraleph/3397008 https://twitter.com/rauschma/status/1269964154275799041
my bad, I learned something new.
anyway this proves that immutable data structures are not inherently slow, this is infact an optimization that makes things faster.
Earlier quoted context omitted.
I have a here 90 second .gif I made a year ago (demo of a particular Vim syntax highlighting scheme for a commit message format). It contains 930 frames, 10 fps. The resolution is 1200x768. The .gif is 600.0 kilobytes, so the coding density is about 660 bytes per frame. Someone downloading at 3-4KB/s might find the download annoying; on the other hand, it could play back on a 66 MHz 486 DX they found in the dumpster.…
You're clearly more careful with resource consumption than many, then. Many times I've had enough time to start coffee while waiting for a .gif to get through its first pass so I can usefully watch it, using rural satellite from Hughes. We're still using your stuff out here.
Gifs can do silly things, like store a sequence of full frames.
Earlier quoted context omitted.
Won't make them slower, anyway. There are often performance bottlenecks you didn't know about, and had blamed on database (or whatever) interaction overhead. It will never feel worthwhile to dig into each candidate, because any payback seems too unlikely. Not having left scope for such bottlenecks means you can be confident they are not there. Re-implementing once is a lot less work than diving into each possible bot…
> Any optimization you could do in Rust is probably easier in C++ That's kind of funny in light of the history that certain optimizations in web layout engines were attempted, unsuccessfully, in C++ multiple times and ultimately they invented Rust to make them easier.
The facts on the ground probably have more to do with improvements to the C++ code being obliged work as deltas against existing C++ code, where the Rust code was a complete re-implementation, thus not constrained.
Both C++ and Rust are today different languages from when that project ran.