Open Rich-Harris opened 7 years ago
~It also doesn't (completely) work in Safari 5.1: the querySelector(':checked')
always returns []
~
I marked this as a v1 Q, but it's also relevant to v2-- I think it's just a matter of documenting the expectations. Is this documented somewhere other than the blog post, or is that sufficient enough?
The lack of some sort of official browser support matrix is what is preventing me from being able to use Svelte at work. IE11 & Safari 10 support is what I'm particularly interested in, although others may need support for older versions of those browsers as well.
I haven't had a chance to try out this ESLint plugin yet, but I wonder if this will answer our question: https://github.com/instea/eslint-plugin-builtin-compat
@JohnRiv If you want to use v2.0.0+, the ES5 constraint was dropped (#1359). I'm currently using it in a very old webkit environment by polyfilling it with @babel/preset-env
and it's working fine (for now).
IE11 const
in for
not supported
Any news on that? I'll probably run it with @babel/preset-env
, but know which polyfills I'll need could be very helpful.
It will be nice to have a browser support policy on the website or docs. Will be good for using Svelte in big business.
I'm bumping this - cause I got my org on board with Svelte, and am working to support IE11. I got 100% of the way there with: https://blog.az.sg/posts/svelte-and-ie11/
But then we added in some async/await stuff for grabbing data, and everything is broken again. I feel like we are getting pretty close (I'm sure it's just the right magical combination of Babel, Nodent, core-js, regenerate, etc....) but I have been plunging the internet for a few days trying to find the missing link.
Cheers though otherwise. Once this works, we will be flying high.
This just in: we needed Babel for polyfilling all the promise, async/await stuff etc. But we also needed: https://github.com/github/fetch to Polyfill the fetch. And now things are working in IE11. If anyone else gets stuck with this, bug me. I know very little, but I can at least describe how this works, and what we did to get it there. hahaha! Cheers!
@andrewdc yes please go ahead and give me your configuration I'm interested
If anyone is interested I made an app around Christmas which supported ES6+ for modern and ES5 for older Browsers in parallel.
@andrewdc yes please go ahead and give me your configuration I'm interested
So, here is the config chunk for our Legacy bundle. I recommend the Rollup plugin polyfill, as it will inject the whatwg-fetch
polyfill automatically.
Unfortunately, all of this stuff inflates the bundle a huge amount, but it all does work. Hope this helps.
{
//Legacy Bundle creation
input: !production ? "src/index.ts" : "src/components/components.module.js",
output: {
file: "public/bundle.legacy.js",
sourcemap: false,
format: "umd",
name,
},
plugins: [
svelte({
dev: false,
emitCss: false,
}),
resolve({
browser: true,
dedupe: importee =>
importee === "svelte" || importee.startsWith("svelte/"),
}),
commonjs(),
json(),
babel({
extensions: [".js", ".mjs", ".html", ".svelte"],
runtimeHelpers: true,
exclude: ["node_modules/@babel/**", "node_modules/core-js/**"],
presets: [
[
"@babel/preset-env",
{
targets: {
ie: "11",
},
useBuiltIns: "usage",
corejs: 3,
},
],
],
plugins: [
"@babel/plugin-syntax-dynamic-import",
"@babel/plugin-syntax-import-meta",
[
"@babel/plugin-transform-runtime",
{
useESModules: true,
},
],
],
}),
polyfill(["whatwg-fetch"]),
preprocess,
terser(),
],
watch: {
clearScreen: false,
},
},
My approach which only loads legacy code for older browsers.
{
// all polyfills are referenced here
input: 'src/polyfill.js',
output: {
sourcemap: true,
format: 'iife',
name: 'app',
file: 'public/legacy/polyfill.js'
},
plugins: [
// cleanup
del({ targets: 'public/legacy/*' }),
// If you have external dependencies installed from
// npm, you'll most likely need these plugins. In
// some cases you'll need additional configuration —
// consult the documentation for details:
// https://github.com/rollup/rollup-plugin-commonjs
resolve({
browser: true,
dedupe: importee => importee === 'svelte' || importee.startsWith('svelte/')
}),
commonjs(),
notLocal && terser(),
]
},
{
// ... svelte build
}
my html setup:
<script type="module" src='/bundles/bundle.js'></script>
<script nomodule defer src="/legacy/polyfill.js"></script>
<script nomodule defer src="/legacy/bundle.js"></script>
my build command:
"build": "rollup -c && npx babel public/bundles --out-dir public/legacy --presets=@babel/preset-env",
which uses the following:
devDependencies:
"@babel/cli": "^7.7.0",
"@babel/core": "^7.7.2",
"@babel/preset-env": "^7.6.3",
"browserslist": "ie 11"
I now have also specifically heard this as a reason some companies consider svelte experimental and not ready for wider adoption. the matrix does not even have to be huge, just to have one at all communicates reliability and production readiness.
This is a big deal. I think svelte would be perfect for a requirement at work, but I can't recommend it without an official browser support list. I'm sure I'm not the only one. Here's to having an excuse to learn svelte soon! 🍻
but I can't recommend it without an official browser support list.
While it doesn't have an official browser list, via babel and/or polyfills you can pretty much support all the way back to IE 11 and similars.
If the Svelte team decides on a browser support matrix, it would be easy to maintain compatibility with the use of https://github.com/amilajack/eslint-plugin-compat
If a browser support list is all that's needed to resolve this, I think a quick audit in https://github.com/sveltejs/svelte/tree/master/src/runtime would cover most cases. If anyone likes to do so, we could start with a community-supported list and work from there until it's officially endorsed.
Any news on this? I do feel like just knowing the support audit is more than enough. It's crucial to have a quick table ("Yes, supported" / "No, unsupported") to let Clients know what it'll be like when their site is up and running.
Something like this, for instance.
A browser support table is essential for assessing svelte-kit's eligibility for commercial projects.
Just wanted to +1 a simple browser support table or list. There have been more browser compatibility issues with Svelte for our users than I would have expected.
I was trying to get a statically rendered sveltekit site to run on an old Chrome 58, and run into it being unable to handle these dynamic imports that sveltekit uses in index.html
:
https://github.com/sveltejs/kit/blob/18b0599015f32e6c829eb005eab960a999cf8c6c/packages/kit/src/runtime/server/page/render.js#L359
Caniuse.com says dynamic import is supported from Chrome 63, Safari 11.1 and Firefox 67. So anything older than this is definitely not supported by Sveltekit: https://caniuse.com/es6-module-dynamic-import
I tried a slightly less old Chrome 69 and this time got an error about globalThis not being defined, which I believe comes from here: https://github.com/sveltejs/kit/blob/18b0599015f32e6c829eb005eab960a999cf8c6c/packages/kit/src/exports/vite/index.js#L347
There was no globalThis until Chrome 71: https://caniuse.com/?search=globalThis
Putting <script>globalThis = window</script>
into the head of the app.html file fixed this.
EDIT: Also I now realize this is not the sveltekit repo...
Svelte really shines in the embedded space, where browsers are quite underpowered and React's virtual DOM overhead would have a very noticeable impact on performance. I haven't tested these, but my wish list for more exotic supported web runtimes would be
Is there any plans to work on documenting browser support? Are there any community-maintained resources about this? The lack of info on Svelte and SvelteKit browser compatibility and required polyfills is frankly very concerning and discouraging when evaluating Svelte for any commercial use.
The lack of info on Svelte and SvelteKit browser compatibility and required polyfills is frankly very concerning and discouraging when evaluating Svelte for any commercial use.
SvelteKit 2 states that ES2022 is required.
SvelteKit 2 uses ES2022 features, which are supported in all modern browsers.
https://kit.svelte.dev/docs/migrating-to-sveltekit-2#updated-dependency-requirements
These are evergreen browsers that support all ES2022 features.
Browser | Release Date | Release Note |
---|---|---|
Chrome 94+ | 2021-09-21 | Link |
Edge 94+ | 2021-09-24 | Link |
Firefox 93+ | 2021-10-05 | Link |
Safari 16.4+ | 2023-03-27 | Link |
Samsung Internet 17.0+ | 2022-05-06 | Link |
SvelteKit 2 states that ES2022 is required.
SvelteKit 2 uses ES2022 features, which are supported in all modern browsers.
https://kit.svelte.dev/docs/migrating-to-sveltekit-2#updated-dependency-requirements
These are evergreen browsers that support all ES2022 features.
Browser Release Date Release Note Chrome 94+ 2021-09-21 Link Edge 94+ 2021-09-24 Link Firefox 93+ 2021-10-05 Link Safari 16.4+ 2023-03-27 Link Samsung Internet 17.0+ 2022-05-06 Link https://caniuse.com/?search=es2022
This is useful info, but kind of discouraging in and of itself. The ES2022 requirement seems quite restrictive, since according to caniuse, about 1/4 of Safari versions by current usage don't support all ES2022 features. This makes it much more difficult to get good browser compatibility and good bundle size with SvelteKit.
Also, ES2022 as far as I know does not include Web API-s, so there's still the question of what Web API-s need to be polyfilled for good compatibility.
Attention: this seems to have been deleted from the official page and seems no longer true:
(not present anymore!) SvelteKit 2 uses ES2022 features, which are supported in all modern browsers.
https://kit.svelte.dev/docs/migrating-to-sveltekit-2#updated-dependency-requirements
I guess there's still no official support table for svelte either. Would be great at least to have for svelte 5. :)
Edit
Just searched the main branch (svelte 5
's source), and since it uses Map in runtime functions like packages/svelte/src/internal/client/runtime.js it seems safe to assume that the minimum is ECMAScript 2015 (ES6)
that introduced Map and Set.
Github seems to index only the main branch for search operations, so if you want to know support for svelte 4
you would need to clone that branch (or open it in the web IDE) and start a full search for the properties you are interested in.
For additional context, the following sentence was removed in:
- SvelteKit 2 uses ES2022 features, which are supported in all modern browsers.
This is possible because top-level-await is no longer used.
https://github.com/sveltejs/kit/pull/11688#pullrequestreview-1833357460
To enforce a specific build target, set it in the vite.config.ts
file.
https://github.com/sveltejs/kit/issues/11658#issuecomment-1904125554
SvelteKit v1 used the Vite default value which is close to ES2020.
https://github.com/sveltejs/kit/issues/11658#issuecomment-1900722813
A few people have asked about browser support. We probably should be able to answer the question conclusively (maybe even running some tests in Browserstack or whatever?), and perhaps tell people which polyfills they'll need.
For example,
window.performance.now
isn't supported in IE9, but is used in transitions (https://github.com/sveltejs/svelte/pull/525#discussion_r114223085).