-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Break out individual compilers #1678
Comments
Yes please :) |
move render logic out of node objects
You have my full blessing. I love the heck out of this. |
👍🏽 yes, please! 🎉 |
@benmccann what exactly remains? As I can see Rich has already done the main things. |
What would we expect the API to look like? From what I can see we can pass in a new compiler in src/compiler/compile/index.js. Could we make the I am also interested in using svelte for pixi or three js so I'm pretty curious about how you'd mix and match components so that some are compiled to DOM nodes and some are compiled to three.js objects. Would it be preferred to make a threejs compiler fallback to the default compiler and if so are the correct functions exported? |
As frequenters of the Discord server will know, I'm become obsessed lately with the idea of compiling Svelte components to WebGL code (not for UI, but for building 3D/VR scenes — the sort of thing you'd traditionally use Three.js or A-Frame for). The easiest way to try this out would be to create a new compile target inside Svelte itself, but that would be somewhat disruptive for something that may turn out to be completely impossible.
An alternative, which I think is worth doing anyway as it would be good for the codebase, is to break out different compilers into their own packages. So instead of every
Node
subclass implementingbuild
(for thedom
target) andssr
(for thessr
target), the program generated in the initial phase would be handed off to a compiler, which would return something like a{ code, map }
object (or otherwise something that can be easily turned into one, if that makes more sense in terms of code reuse etc).So we'd have
@sveltejs/compile-dom
,@sveltejs/compile-ssr
and (eventually)@sveltejs/compile-gl
, each implementing the same interface. In time we could even add to that list —@sveltejs/compile-native
,@sveltejs/compile-tty
and so on.In all likelihood this would need to be accompanied by separate runtime libraries for the different targets —
@sveltejs/lib-dom
,@sveltejs/lib-ssr
,@sveltejs/lib-common
(whichdom
andssr
would re-export from).Aside from all the speculative VR stuff, I think this would probably make the codebase less intimidating for new contributors, and it would be good discipline. (The
svelte
package would still bundle everything, we wouldn't have a nightmarish situation with peer dependencies getting out of sync.)Any thoughts?
The text was updated successfully, but these errors were encountered: