Show HN: Imgix.js, a JavaScript library for responsive imaging
1–10 of 33 posts
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#2I wonder why are there so many services that work with this kind of business model. while I would be willing to pay for code I can own, I would never invest in something in something where I can't predict it's future.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#3This is nice, but it does not put a valid img tag in the document source without javascript execution. That might be fine for things that don't face the public internet, but if you do any type of public publishing, you should care about having markup that describes your content independent of scripts or css.
This is why standard markup-based responsive images (picture and srcset) are such a big deal.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#4This is nice, but it does not put a valid img tag in the document source without javascript execution. That might be fine for things that don't face the public internet, but if you do any type of public publishing, you should care about having markup that describes your content independent of scripts or css. This is why standard markup-based responsive images (picture and srcset) are such a big deal.
There is nothing stopping you from setting the src tag. But you are just adding another request. Our base service works perfectly with src set and picturefill. This library is for cases where a different result is desired.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#5I wonder why are there so many services that work with this kind of business model. while I would be willing to pay for code I can own, I would never invest in something in something where I can't predict it's future.
I can't speak specifically about this responsive image feature, but as for imgix's core business, I have mixed feelings.
It's pretty trivial to write on-the-fly image processing using an existing graphics library. And given that the image can be cached and served from disk and a CDN, it can scale incredibly well.
Having said that, the features that they support is impressive, the API is intuitive, the speed is great, and you can stick your own CDN infront of it (or use theirs, which is actually Fastly, I believe). The founder, Chris, is wicked smart...this is really more than just a wrapper around GM.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#6Title is "for responsive images", not "imaging".
Imaging is completely different!
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#7Title is "for responsive images", not "imaging". Imaging is completely different!
What is your definition of imaging? Our use of imaging is in reference to imaging in technology. "The production of graphic images from digitally generated data." Our service processes images on our servers and produces new image data with each request when necessary (if not cached already.) The Javascript library is just a way to interface with our infrastructure and generate these requests.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#8I wonder why are there so many services that work with this kind of business model. while I would be willing to pay for code I can own, I would never invest in something in something where I can't predict it's future.
There are at least couple open source projects that handle dynamic image generation on the backend quite nicely. It seems photon is dead, but I found it works quite well and is easy to extend. Thumbor seems quite active although I've never used it myself.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#9This is nice, but it does not put a valid img tag in the document source without javascript execution. That might be fine for things that don't face the public internet, but if you do any type of public publishing, you should care about having markup that describes your content independent of scripts or css. This is why standard markup-based responsive images (picture and srcset) are such a big deal.
There is nothing stopping you from setting the src tag. But you are just adding another request. Our base service works perfectly with src set and picturefill. This library is for cases where a different result is desired.
Why isn't there an img-tag in the default example? Why are you promoting bad practice by not having images in img-tags? You solved one problem but created a much bigger problem. Bots, screen readers and non-javascript client should see an image, not a div with some attributes.
Re: Show HN: Imgix.js, a JavaScript library for responsive imaging
#10I wonder why are there so many services that work with this kind of business model. while I would be willing to pay for code I can own, I would never invest in something in something where I can't predict it's future.
There are at least couple open source projects that handle dynamic image generation on the backend quite nicely. It seems photon is dead, but I found it works quite well and is easy to extend. Thumbor seems quite active although I've never used it myself. https://github.com/thumbor/thumbor https://github.com/1000Memories/photon-core
One that I wrote, written in Ruby: http://magickly.afeld.me/ Powers http://mustachify.me :3)