Svelte: Roadmap

[Rich-Harris]

As pointed out by @dylanpiercey, it would be good to have a publicly available (and discussable) roadmap that we can point people towards when they have questions about e.g. CSS preprocessors and what-have-you. It will also help us triage issues. This can encompass the wider ecosystem, not just the compiler itself.

Throw your ideas in, and I'll update this issue — the list below is a bit vague and is just to get us started.

Immediate priorities

• [ ] Bug fixes should always be at the top of this list, unless fixing them involves major refactors and/or breaking changes
• [x] #604 — pkg.svelte to enable more efficient distribution of components
• [x] #577 — full page rendering (and a set of conventions/starter project template for universal Svelte apps that takes advantage of it, which could morph into a full next.js clone)

Medium term

• [ ] #374 — A11y
• [ ] Better transitions — there are some places we can make them more efficient (reusing <style> tags etc). Support for staggered transitions would be very useful as well, since it would enable e.g. out-in behaviour and other things
• [ ] Figure out some blessed conventions for automated testing of Svelte components
• [x] Figure out some blessed conventions for routing, as it comes up a lot
• [x] Support non-standard CSS/JS (TypeScript, ES20xx) — probably as an officially supported preprocess step rather than in core, unless we want to make compile async
• [ ] Better infrastructure around error messages and warnings — it's a bit ad hoc in places
• [x] #469 — decorators
• [ ] HMR — official, document hooks

v2

• Disable CSS cascading
• Remove deprecation warnings
• Syntax changes? E.g. something that looks less like {{mustache}}. Maybe adding the by thing.id syntax for keyed each blocks

Longer term

• Editor plugins (syntax highlighting inside tags, etc)
• App-level (not just component-level) static analysis, for finding e.g. unused data
• Compiler hooks (being deliberately vague here — would be great if the compiler was flexible enough to allow plugins that could e.g. automatically wire up mobx/GraphQL/etc)
• An online component editor (like the REPL but more sophisticated — make it easy to save components, import other people's components, embed them on other websites a la CodePen, etc. More ambitiously, I have a long-standing dream of creating a component editor that allows you to switch between template, XML tree and WYSIWYG views, loosely based on this Bret Victor video

Maybe one day

* [ ] Support separated { html, css, js } input

[TehShrike]

Looks awesome. Think there's any room for decorators in the medium term? (https://github.com/sveltejs/svelte/issues/469)

[PaulBGD]

I've been looking at editor plugins (and had a sample IntelliJ/WebStorm plugin working) but haven't had time to look over documentation for other popular editors, such as Sublime/VSCode/Atom/Emacs. The biggest issue with this one is that each editor has a completely different API for adding support for another language, and some editors only support plugins in a specific language (python or java for example.) I'll make an update when I have a PoC for editor support.

[constgen]

Can we add Hot Module Replacement support at least to v2?

[Rich-Harris]

Updated to include decorators and HMR. @constgen what would be involved in getting that to work? Are we talking about something webpack-specific, or is there a more agnostic approach to HMR?

[Ryuno-Ki]

Why do you want to turn off CSS cascading?

Do you know Frontend Creator (written in Aurelia)?
I wonder how a framework, which runs on a server, should be put together interactively on the browser...

Concerning editor/IDE plugin support, there was an abstraction layer, but I forgot its name. Oh, the list lacks Vim btw.

Concerning Compile-to-JavaScript languages, don't forget Elm.

[constgen]

I meant API ready for integration with existing HMR environments like Webpack. We need to have an access to all instances of a given component.

[Rich-Harris]

Why do you want to turn off CSS cascading?

See rationale on https://github.com/sveltejs/svelte/pull/607 — tl;dr leaner CSS, fewer footguns, better static analysis, etc

Do you know Frontend Creator (written in Aurelia)?

No, looks interesting.

I wonder how a framework, which runs on a server, should be put together interactively on the browser...

https://svelte.technology/repl

[Ryuno-Ki]

After reading #607 and #583, I see, that mainly components are on your mind. What about cross-component like typography, theming or grids?

What does :global do different than :root *?
Whereas :root usually points to html.

[DylanPiercey]

Would be awesome if svelte got a basic dependency injection :).

Similar to:

• React and similar contexts
• Hanldebars { data }
• Marko { $global }

It makes a few things much simpler such as routing where you typically want the route information available in any arbitrary component. This currently works fine in the browser since the global scope isn't shared but currently if you wan't to do this with svelte in the server side you are limited to domains or similar approaches.

[arxpoetica]

We've set up a project for this: https://github.com/sveltejs/svelte/projects/1

[PixievoltNo1]

I'd like to propose that #195 and either #368 or #881 get on the roadmap.

[qm3ster]

Shouldn't a lot of this be ticked? Or does sapper not count yet?

[Rich-Harris]

@qm3ster Some of it, yeah — have updated the list

[raven78]

I share your dream...

An online component editor (like the REPL but more sophisticated — make it easy to save components, import other people's components, embed them on other websites a la CodePen, etc. More ambitiously, I have a long-standing dream of creating a component editor that allows you to switch between template, XML tree and WYSIWYG views, loosely based on this Bret Victor video

Bret Victor videos is the underlying reason that made me try svelte among other frameworks.
This dream calls for early preparation on svelte part and some long discussions.
I have some thoughts, some are general and some are more specific.
@Rich-Harris , if you are interested, I will put them on paper and search for a good place to post them.
It will be a long read...

[arxpoetica]

@raven78 count me interested

[ShimShamSam]

+1 for compiler hooks. I think it would allow for declarative GraphQL queries based on the properties used within your templates.

[mckenziewagner]

+1 for some vim/neovim syntax and/or language server integration

[pngwn]

@ShimShamSam Compiler hooks are probably not going to happen (not any time soon, but probably not at all), could this be achieved in a preprocessor?

[burner]

syntax highlighting for (n)vim

https://github.com/burner/vim-svelte

[cwahlfeldt]

@burner you da f*ing man! Thank you so much!

[burner]

thank the good people from https://github.com/posva/vim-vue
my thing is just a copy/paste/modify from that

[cwahlfeldt]

thank the good people from https://github.com/posva/vim-vue
my thing is just a copy/paste/modify from that

Thats awesome annnd I dont have to do any work :) Cheers!

[evanleck]

For anyone interested, I made a new Vim syntax highlighting and indentation plugin at evanleck/vim-svelte. It piggybacks on the HTML syntax but adds JavaScript highlighting for anything between { and } as well as some Svelte-specific keywords like #if, #await, :else, etc.

[JoshuaJWilborn]

I would love to see lang server integration in VIM so I can pick svelte up more seriously...Not having auto complete is a deal breaker for me :(

[HunderlineK]

@Rich-Harris I feel this is not being updated anymore? I keep checking this page every other month hoping to see if it's changed 🙈 Is there another up to date roadmap?

[pngwn]

This isn't _really_ an up to date of view on where we are and where we would like to go. We have some tentative plans to improve how we communicate the 'roadmap' in the future. We'll update when we know more.