stereobooster

Think of it like Algolia, Typesense, Meilisearch, but done without server - directly in the browser.

Online demo: https://facets-demo.stereobooster.com/

Thanks for this response, this is very helpful. I will update post with this concern

Module size is ~7Kb. A detailed comparison is here https://github.com/stereobooster/react-ideal-image/blob/mast...

The discussion on performance is too focused on mobile

Because mobile users have a slower internet connection and worse CPUs.

What kind of performance are you talking about? If load performance, then this component uses well-established techniques (not invented by me), like lazy-loading (known since jQuery times), srcset (web standard), LQIP (used by Facebook, Medium), width, height (required for all blocks in AMP).

If you are talking about JS performance like frame rate or paint or "junk" on the scroll - I didn't measure it but didn't say it was the first target either.

But not this component. This component will load images without JS. Test it yourself https://stereobooster.github.io/react-ideal-image-experiment...

What you are talking about is more like graceful degradation. If server side rendering is used you will be able to see content ASAP, but not able to scroll, because interaction is blocked by JS. But if you will visit page with JS disabled you will get what you want, because component generates img in noscript tag and you will be able press space to scan the page

Oh yes. More than one

This component supports solid color as placeholder. The same way as Google Images or Pinterest do

I'll definitely take your use case into the consideration in the future

Ok I see your use case: you load page on good connection, then connection get worse and images are not loaded when you scroll to it.

This component allows to retry image load (click on it).

It can be even more smart, like if network is good go ahead and download everything. Need to think about it

It supports retina/3x. Provide big enough image and it will use it. It takes into account `devicePixelRatio`

maybe default max width of 100% on mobile?

It is.

optional ability to overlay an empty full size block so the image cant easily be right clicked and saved

Not sure what you mean, but as soon as image loaded it turns into good old image, so you can do right click

It supports SVG placeholders. SVGs need to be converted to data URIs, like `data:image/svg+xml,%3csvg xmlns='...`, and it works the same as LQIP. You can use https://github.com/stereobooster/sqip.macro to generate those

Can you explain why?

Read this https://github.com/whatwg/html/issues/2806

Again Crystal is not Ruby. https://github.com/crystal-lang/crystal/issues/4731#issuecom...

we might never get static typing for Ruby anytime soon

Yes we will not get type declarations as a part of Ruby syntax anytime soon, but this doesn't mean we can not have static type checking right now

Crystal is not Ruby. Please do not advertise it as a drop in replacement. https://github.com/crystal-lang/crystal/issues/4731#issuecom...

Imagine you have a big ruby project in production and you want to add static type checking. You won't be able to use Crystal for it, while the idea behind Diamondback Ruby is to be able to integrate it gradually.

The reason is to fight with bugs, which are caused by type errors. Current approaches are:

1) use guards 2) add tests which check types 3) use error reporting software, like Sentry, and cath errors in production

Is there any reason you do not want not catch type errors without additional code and useless tests before you deployed it to production?

https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

This rather tends to be a middle ground solution while we do not have an idea how to do types right in Ruby. Let me remind you that whole Ruby core team struggles with this question. But this thing can work with original source code without modification or with type annotations in comments, so it intentionally stays out of Ruby syntax.

it only supports 1.8

Yes, it is because this is a fork of a project started in 2009 (and not maintained afterward). I spent a couple of evenings trying to resurrect it and see what this thing is capable of. There is a lot of things to do to make this really usable. But I was able to get it to the point to run examples (those examples are the same in ruby 2.4).

But those are for dynamic typing. I was looking for static typing

RDL and Diamondback have a different approach. Diamondback works with given code without modification and able to find (some) errors, RDL needs code modification. See this issue https://github.com/plum-umd/rdl/issues/33#issuecomment-31707...