Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

4x Smaller, 50x Faster

blog.asciinema.org

Post reply on HN
Print view View original

91–100 of 205 posts

Re: 4x Smaller, 50x Faster

#91

Post by sickill »

eatonphil wrote: post #6

Historically asciinema was not easy to embed in React because you can't have multiple copies of React. So my team at the time wrote and open-sourced an embeddable alternative to it. Unfortunately that project seems to have disappeared by now. But now that asciinema is no longer in React maybe it will be possible to embed now. See https://github.com/asciinema/asciinema-player/issues/72#issu... .

Yup. No more React.js conflict. That was caused by the way how ClojureScript bundle has been built (reagent's copy of React added to the bundle's global/window namespace).

Also, the dependency on Solid.js is unlikely to cause any conflicts even if you used Solid.js yourself in your app given the new package doesn't globally export anything else other than the minimal public API for mounting the player in DOM.

Re: 4x Smaller, 50x Faster

#92

Post by sickill »

kazinator wrote: post #15
eatonphil wrote: post #6

Historically asciinema was not easy to embed in React because you can't have multiple copies of React. So my team at the time wrote and open-sourced an embeddable alternative to it. Unfortunately that project seems to have disappeared by now. But now that asciinema is no longer in React maybe it will be possible to embed now. See https://github.com/asciinema/asciinema-player/issues/72#issu... .

Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.

> no third party websites

FYI you're not forced to use asciinema.org for hosting the recordings, it's fully self-hosting friendly: https://github.com/asciinema/asciinema-player/#quick-start

Re: 4x Smaller, 50x Faster

#93

Post by hnarn »

atoav wrote: post #51

While I applaude the engineering effort that went into the project, I really dislike documentation that uses asciinema for regular non-interactive CLI interfaces: instead of showing me the commands in an overview I have to sit through the whole thing.

Documentation does not belong in asciinema. It’s for presentation, and using it as an excuse not to document is pure laziness.

Re: 4x Smaller, 50x Faster

#94

Post by uasi »

ReleaseCandidat wrote: post #73
atoav wrote: post #69

Earlier quoted context omitted.

It has, if the thing you are showing fits the media. If you show the different flags of ls without explaination you would be better of just showing me the printout of ls -h If you are showing off some beautiful TLI, an interactive prompt or ascii animations, this is the perfect tool. As someone who works in film: film also doesn't lend itself to everything. Certain internal observations that work great in literature…

> If you are showing off some beautiful TLI, an interactive prompt or ascii animations, this is the perfect tool. If you want to just show something off, a GIF (or real video) is the answer. The defining feature of asciinema is that you can copy the text out of the animation. Which is actually not that useful most of the time, because you can't search for text in asciinema (AFAIK?) like you can in, well, documentatio…

> a GIF (or real video) is the answer.

Why so? You can't pause or seek GIFs. GIFs and video files are usually several times larger than asciinema recordings of the same content. And you can't copy text out of them when it is useful.

Re: 4x Smaller, 50x Faster

#95

Post by qwertox »

ReleaseCandidat wrote: post #76
omnicognate wrote: post #71

Earlier quoted context omitted.

Ew, people are using it for docs? It always seemed clearly to be for those quick-look demos on projects' home pages, and it's fantastic for that.

What exactly is the advantage of asciinema over a video or a GIF if you're just showing something? If I don't need to copy text out of it, it has the same function as a video.

I'd guess it's the bandwidth and compared to a GIF, you can pause them. While it's not usual to copy text from it, I've done that once this month and thought it was neat to be able to do that. I do believe that they have an advantage over video/GIF.

Re: 4x Smaller, 50x Faster

#96

Post by mping »

lxe wrote: post #2

The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.

Well the immutability hype allowed the author to build the previous incantions of the library. At this point, I hoped everyone understood the tradeoffs of using abstractions. Otherwise we should all be programming on assembly.

Re: 4x Smaller, 50x Faster

#97

Post by gpderetta »

fulafel wrote: post #47
notacoward wrote: post #8

Earlier quoted context omitted.

How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? I've certainly seem some code written in an "immutable" style where it was pretty clear that the intent was for one data structure to be a mutation of another, just called something else because the language required it. That case might be easy to optimize ... but the general case?

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

Re: 4x Smaller, 50x Faster

#98

Post by sickill »

fnordsensei wrote: post #86
badestrand wrote: post #80

Earlier quoted context omitted.

> Due to ClojureScript’s immutable data structures, there’s a lot of objects created and garbage collected all the time ^ From the article, sounds like a plausible cause for the speed difference.

It's almost certainly part of it. I doubt that a ClojureScript application written mutably (which you can do) would compare favorably to WASM regardless.

Before attempting JS/Rust rewrite I tried using transients [0]. I converted small part of the vt code to use mutable data structures to see if it's giving any improvements. It barely did, the difference was negligible. I believe it was because I didn't go all the way, so the perf critical pieces deep down were still using immutable data structures. Maybe it would bring decent improvement if I converted most of the vt code to transients, but it would absolutely destroy the idiomatic aspect of the code, and even then it would never compete with Rust anyway.

[0] https://clojure.org/reference/transients

Re: 4x Smaller, 50x Faster

#99

Post by merijnv »

notacoward wrote: post #7
lxe wrote: post #2

The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.

This part... > for the high frame-rate, heavy animations this puts a lot of pressure on CPU and memory ...does seem to suggest that the "garbage multiplier" effect of immutability is an ill fit for applications that also create a lot of garbage naturally. Note that this is about as close to an apples-to-apples comparison as we're likely to get - the same application implemented two different ways - so it's not the ap…

> ...does seem to suggest that the "garbage multiplier" effect of immutability is an ill fit for applications that also create a lot of garbage naturally

That actually depends on how your GC is implemented. For example, due to laziness+immutability, Haskell produces a lot of garbage and a lot of allocations. This is not a problem with the GHC compiler, as the GC design makes allocation cheap (effectively a bump pointer allocator) and GC cost scales with the amount of non-garbage (this is, like all GC design, is a trade-off that can get you into trouble with some workloads).

Re: 4x Smaller, 50x Faster

#100

Post by skrebbel »

ryansolid wrote: post #16

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 worked quickly got in the way.

Solid still puts the components firmly at the center, just like React, but replaces React's state concept by fully reactive observable state, called "signals". You use them pretty much like you useState in React, but deep inside it's an observable stream of changing data, and you get all the finegrained update control that comes with that.

Also, I love how noun-heavy it is. Resources, tracking scopes, effects, signals. It's just like how React moved from "do this thing after the component updated" to "ok we have this concept called an effect", but extended to more topics such as dealing with async data loading, when exactly a signal is observable, etc.

Post reply on HN