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
• RFC: Convention for packaged components to export uncompiled templates #604 — pkg.svelte to enable more efficient distribution of components
• Full Page Rendering #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

• A11y and being a good citizen of the web #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 - will happen in SvelteKit
• Figure out some blessed conventions for routing, as it comes up a lot
• 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
• Decorators/hooks #469 — decorators
• HMR — consider making svelte-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? (#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 #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

[ghost]

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.

[Ataginsky]

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.

@pngwn or @Rich-Harris any news about this ?

Not to mention a roadmap in the form of a ToDo list, do you have (maybe on Discord ?) an explanation (for developers using Svelte) of future plans for Svelte.

• Where Svelte v3 is going ?
• When is the next big relaese (v4) ?
• What to expect in it ?

In general, what about creating a more rebust delivery system for Svelte (ala Angular/Reack/Vue - where we know what the direction is and when to expect it) ?
Or if the system exist, what about communicating it ?
I know about svelte blog and 'Whats new in Svelte this month', but I'm talking about future releases, future deprecations, major upcommng features, etc...

What about Svelte project itself ? The use of Vue.js only exploded after Evan You and others started working on it as full-time job. Do you have plans to raise funds and put people full time on Svelte ? I would have gladly supported this initiative.
I think it's time for Svelte to take it to the next level. There's a lot of work to do, and Svelte's biggest issue right now isn't about 'Can it scale' or 'Are big projects done with it', but:

• 'What support (for the project) can I expect in long term (LTS) ?',
• 'Will it notify me about depreceting changes to smooth update to the next version ?',
  • Personaly, I'm still using v2 on a big project because of the damage caused by the big breaking changes of v3...
• 'In 1/2/3/4/5 years, will the project be supported at all ?'

=> Theses are the real reasons that slow down mass adoption, big players carrying out big projects, etc...
People need to be reassured about the future of Svelte AND tooling ! And that goes hand in hand with a robust ecosystem.

[benmccann]

I'm going to go ahead and close this issue since the roadmap here is so far out of date I think it's not really useful to anyone.

For now, the best place to follow Svelte's upcoming priorities would be to follow the Svelte blog and RFCs. The Svelte blog has announced major changes like Svelte 3 and SvelteKit while most major features to the core Svelte library have gone through RFCs.

SvelteKit does now accept donations via OpenCollective.

Svelte 2 to 3 was a large change from my understanding (I only started using Svelte after v3 was released). As far as I've seen, there's been an avoidance of major breaking changes since then and no interest in having large breaking changes in the future

Major improvements have been made in tooling including TypeScript and VS Code support