It *might* have to do with lit re-exporting directives from lit-html as a transitive implicit dep. AFAICT would still be a bug of the vite plugin if it cannot handle that, so nothing wrong about it from lit perspective I think. Just a symptom of sharing not working correctly.
Posts by Simon Ihmig
No, you can explicitly declare shared deps to be treated as singletons. However, that was not working for me as described in this issue: github.com/module-feder...
Which brought up the issue of lit in dev mode and lit-html in prod clashing, as the latter was not properly shared for some reason.
New ResponsiveImage release is officially out of the shell! ๐ฃ
๐ Full support for @vite.dev v8 and @rolldown.rs optimization.
โจ Smoother DX: polished defaults and other ergonomics improvements
๐ณ Dropped some eggs, breaking support for Node 20 and Ember < 6.4
responsive-image.dev
๐ฃ responsive-image.dev now ships with a native Vue.js image component to render responsive images!
Use it with the @vite.dev plugin (or webpack) to process local images in your @vuejs.org or @nuxt.com app, with support for modern formats, image transformations and LQIP, or load from image CDNs.
Hot off the press!
6.8 released with some big features ๐
โก@vite.dev by default
๐ Compatible with libraries from 8+ years ago*
โจ New APIs: renderComponent, additional reactive data structures
๐ค No more hbs by default (strict: true)
Read more here:
blog.emberjs.com/ember-releas...
Been a while since my last blog post, so I thought I'll write this one on the open source project I spent a fair amount of time on over the last year.
Are you building web applications and want to deliver responsive images in an easy and efficient way? Then give this a read ๐
dev.to/simonihmig/i...
New major release of responsive-image.dev is out!
โ image component for @react.dev
โฑ๏ธ supports the @fastly.com IO image CDN
๐ supports auto-negotiation of image format by CDNs
โจ refactored LQIP (Thumb/BlurHash) simplifying runtime image components
Shoutout to William Killerud for most of these! ๐
๐ ๐ ๐
@warp-drive.io (formerly #emberdata) version 5.5-alpha.21 is compatible with any framework that works with a signals concept. Even multiple on one page sharing data. Pluggable reactivity ftw. Official #svelte/#vue/#preact/#lit integrations coming soon. โจ๐
github.com/emberjs/data...
Render responsive images in your Svelte app with this library by @simonihmig.bsky.social ๐ผ๏ธโก๏ธ - madewithsvelte.com/responsive-i...
A picture taken over my shoulder of me releasing Embroider@v4 from my phone while drinking a beer in a restaurant
I just released Embroider@v4 from the @mainmatter.com team dinner using release-plan
This is the start of the @vite.dev era of @emberjs.com ๐
ChatGPT is savage. omg
And how you compose the two worlds together is a legit framework design choice.
I can't see why JS-in-HTML should be semantically or logically better than HTML-in-JS tbh.
All of Svelte is a superset of HTML, or just the templating part? I would say the latter? I am all for the template to be a superset of HTML (don't like JSX), but you need JS at least to glue things together. Most likely your app will host way more JS than HTML though.
Interesting to see that us coming from a similar/same background, we also stumble over the same issues! ๐
Nice write-up!
That wasn't my point though. Yes, you can define features like runes in tests, except for the most basic feature: components.
You can't invoke the component under test in the way you would normally do. Also can't define components locally in your test to pass to higher order components.
Not trying to hate on Svelte, I like it quite a bit!
But I do feel they got this template vs. JS thing backwards.
In Ember tests, you invoke the component just the same way as you do anywhere else. Because you can have <template> inside JS. Example: guides.emberjs.com/release/comp...
Besides the snipped argument, you see the limitations of "js inside template" also for tests. You need to pass props to the render function, invoking the component in a totally different way than you would do in app code. Just because you cannot have template code inside JS.
I think modern Ember nailed it. Instead of .svelte being a template with an island of JS, Ember's .gjs is JS with an island of template. Or multiple.
<template> is just a value, that you can direcly use when in scope (private internal components) or you export it.
guides.emberjs.com/release/comp...
First time learning about snippets I was thinking this must be a workaround due to some architectural flaw/restriction. Why do you need the concept of "snippet", if you already have one of "component"? Only because Svelte syntactically doesn't allow you to define components inside components, right?
This should have been its own post (not hidden in replies), and a blog post, and a talk! ๐๐
Love the vibe!!! ๐ช๐
Thanks, fixed it!
Yeah, I agree.
No, the dimensions are fixed. More details at evanw.github.io/thumbhash/
BlurHash does allow that though: blurha.sh
Kudos to @evanwallace.bsky.social for this beautiful piece!
Find demo and docs for ThumbHash at evanw.github.io/thumbhash/
Docs for the responsive-image.dev integration at responsive-image.dev/usage/lqip#t...
image depicting an aurora borealis in high resolution
a blurry placeholder encoded with ThumbHash
Ever heard of ThumbHash? It's a great way to encode a blurry placeholder image into just a few bytes, 28 here. Like BlurHash but better visual quality!
Available now in responsive-image.dev for @vite.dev or webpack plugins and image components for @emberjs.com @lit.dev @solidjs.com and @svelte.dev!
Good question! Unpic does not have its own image processing capabilities, it requires an image CDN. ResponsiveImage supports that, too (tho not all CDNs yet), but also processing local images in your repo, with its vite and webpack plugins. That's the main differentiator I think.
The responsive-image.dev family got a new member! ๐
๐ Use the new @svelte.dev image component in your Svelte/SvelteKit app to render responsive images, either with our @vite.dev plugin to process local images or with remote images from image CDNs, or both.
responsive-image.dev