Looks great! I really like how you define stuff in context (like min and max) and actually use it somewhere else by drag'n drop in places that look like "text" programming.

And I also like how everything is explorable and interactive.

Nice demo; I've done something similar in Jupyter notebooks; great to see it done visually.

Source code for the plugins is here:

https://github.com/cameronrking/rollup-plugin-svelte-component-ioc transforms the source, converting imports to dependency store injections

https://github.com/cameronrking/rollup-plugin-layout-intercept replaces the application root with a toggleable Golden Layout container (not a huge fan, but it was the easiest to prototype with)

https://github.com/cameronrking/rollup-plugin-ioc-editing-tools is where I'm developing the application tooling

Looks great too!

More than a year ago, I have try something like that, but with Vue.js and using the hot reload stuff but to compile in the browser the modifications. I haven't work again on this, but I thought to reuse it somehow. And even wonder if Svelte would also be a good fit for this kind of scenario. You have just answered that! 😄

I don't really know Svelte (never code) but I really like the concept, and I have to try it. Even if for now I guess I will stick to Vue.js for most of my work.

Anyway, keep going, I am very impatient to see the next iteration!

My first experiments (about 18 months ago) were done with Vue and webpack hot reloading, but before long I ran into weird app blink issues. I'd make a change to one file, and an unexpectedly large portion of the screen would refresh, throwing out state that shouldn't have been thrown out. Plus, hot-reloading relies on architecture outside the browser. This prototype pushes the build and update cycle into the browser as plain JS, so it can be deployed as a static site.

Well, I mean, I used the hot reload feature only in the browser. I.e. the client side part of it. When user makes a modification in an editor hosted in the browser, it fires recompilation/rerender if the Vue template is modified without touching the data, and reload the full component if data is modified. Here is my very light proof of concept: https://stackblitz.com/edit/vue-hot-reload-test-2

Oh wow! I never found that package. I might need to dig into the internals. My Svelte implementation is naive and throws out the whole component every time. Although, I was refactoring the Svelte browser devtools into components that run inside the browser yesterday and discovered that there's a low-level API with $capture_state() and $inject_state() methods, which if they do what they say on the box, should solve the problem neatly.

I have just tried it, and I like it! I like the "vim" like way of executing the command: Alt-o to launch the extension, then 'a' to add, then 'p' for props, then the prop name, and voilà you have un new prop at the right place even if you are far away this place. Combined with the autodiscovery, I find that all this gives a good developer experience.

For the Tailwind part, I find that there is no real plus compared to the existing Tailwind CSS that can already help you finding the right class name with auto complete. I guess for this it is a matter of preference as the experience is slightly different:

• well chosen char sequences for you with autodiscovery
• start typing, auto-completion is showing, select with up/down for Tailwing extension.

I know you won't maintain this extension, but I wanted to let you know that it seems that the extension works well only for 4 spaces tab stops. I use 2 spaces tab stops and after an insertion (say a new props) it uses 4 spaces for the insert and in some other places.

And a remark, this extension is very useful to add data, computed, watchers, etc. with the traditional way of coding this in Vue. But with the new Vue Composition API, maybe it will be more complicated for this extension to add/modify stuff (which can be anywhere in the setup function as JavaScript code) ?

• Yes, that vim-like feel is what I was going for.
• I agree, I think the discovery portion of the CSS isn't much of a change. What really stands out to me, though, is the elimination of the reload and the family navigation mechanic. What I was striving for as I built it was being able to press a single key to iterate through my options without any feedback delay and without having to manually copy changes from the browser back to the source. The shortcut mechanism was intended more for experienced developers who know what they want and want to reduce the number of keystrokes required to say it.
• Yes, the 4-space formatting is intentional. Since it's a prototype, I hard-coded my formatting preferences rather than making them modifiable. But in my defense, it wouldn't be an issue if the AST were a first-class member of the development process. Ideally, I should be able to hand the AST directly to an independent formatter. As it stands, it was easier to rely on the existing integration of formatters/linters into the workflow than to try to integrate those tools directly into the extension or expose the recast printing options. The HTML printer also does some weird stuff with multiple attributes if you haven't noticed that yet.
• The composition API would make life more interesting, but it's intended for more challenging use cases. I haven't had to design anything quite that complicated, so I have no mental models for the process. I wouldn't know what tooling to build, but I suspect it would be closer to a projectional editor than this "smart snippets" thing.

Hi @Cameron King, this looks great! Are you able to go a bit deeper into the technical details of how you achieve liveness? I'm familiar with ASTs but not with Vue or Tailwind, if that helps.

Sure! I'm not sure what you mean by "liveness", but if you're referring to the CSS feedback cycle, the details aren't particular to the technologies.

• To skip waiting for the project to rebuild, the extension opens a WebSocket connection between the editor and the browser. To start the connection, the user has to drop a snippet into their main.js they get through the extension command alt+o ss.
• Through that connection, the extension sends edit-class events, which target an element with a specific data-olympus attribute and add/remove the given classes on it.
• The data-olympus attribute is added to the source code of a given component via an extension command (alt+o ai)
• In the editor, rather than editing class lists directly, the user goes through an input that's summoned by an extension command (alt+o et). Every time the user adds/removes a class, the extension patches the classes on the corresponding AST node and reprints the source, and sends an event through the WebSocket with the appropriate payload.

It could be more elegant and efficient. Editing through the AST isn't necessary, but it was quicker development-wise to work with objects and call .toString() than to work with locations in the underlying string representation. I'm also not a fan of the data-olympus attribute, but it was the quickest way to map identity between AST nodes and live DOM nodes. Neither do I love that the user has to drop a snippet into their source code, but it didn't feel worth publishing an NPM package to hide the snippet. Ideally, the snippet would be part of the build system and included/excluded based on the environment.

Got it, that's perfect, thank you. Yes, by liveness I meant as in live coding or on-the-fly programming.

not sure if intentional but I get an auth error with the OP YouTube link - was the video taken down?

@hamish todd any idea about ^

Apologies folks, fixed now

@Cameron Yick @Orion Reed

@hamish todd Just watched your video and just wanted to say: this is great, thanks for putting a presentation like this together! I had come across the SIGGRAPH 2019 video (linked above) earlier and saw that this is fundamental. Looking forward to hearing more about your work.

Thank you very much for saying! I hope that what I produce with this line of thinking doesn't disappoint 😅