New project fork and alternate organization approach #111
Conversation
|
Hi @briznad - thanks for the work done - I haven't taken a look at it but pretty honoured seeing this work done. So I am stoked studying your approach and let you know my view. But just wanted to give you a quick headsup and appreciation for your contribution. |
|
Hi Brad, upon running the npx create on my windows machine I am getting
You have the same issue? |
|
Hi, After scanning through your changes a few things I like to note
The backdrop of these questions are some of the design decisions I had in mind for ionic-svelte
Next, there are a few fundamental issues that need to be resolved. I am interested hearing how you look at them:
To me it is a very appealing idea taking this to the level you have brought it. As co-maintainer or somehow helping it getting to the next stage. So truly appreciate the effort and looking forward to your view. (haven't tried your demo app yet) |
Good catch! It's working on my machine (MacOS), both locally and when pulling the package down without previously being installed, but I'm sure it's to do with the node version. Looking… yep, there it is. I'm requiring at least Node 18.0.0. But I pushed a commit that swaps out the node method for a 3rd party library. I'd usually prefer to stick with the built-in solution, but the 3rd party supports Node 18+, which will make it less likely people will need to upgrade their Node before they can run the CLI tool. |
|
Two other comments:
|
|
@Tommertom you've raised many good points. Allow me to respond to the more concrete issues, then I'll move on to broader design decisions in a subsequent comment.
I'm not aware of the modal issues you're referencing. I did create an example project, using the @ionic-sveltekit/create CLI tool, to test this: https://github.com/briznad/ionic-modal-footer-test. I'm not currently experiencing any problems. Is there an issue or example repo you could point me to so I can better understand the issue?
You're right that enabling proper view transitions would be difficult without SvelteKit support, but luckily they added the
I'm not aware of the sliding item issues you're referencing. I did create an example project, a copy of the modal footer test repo, to test this: https://github.com/briznad/ionic-sliding-item-test. I'm not currently experiencing any problems. Is there an issue or example repo you could point me to so I can better understand the issue?
I'll need to test this out.
I'll address the larger design perspective, which should also address the majority of the points in from DISCUSSION - Rebuilding ionic-svelte #93 as well, in a moment. |
|
@Tommertom to introduce my perspective of the design principles for this project please allow a slight deviation into why I decided to engage in this project in the first place. As I mentioned, I've happily used your project for a while now, as it combines 2 of my favorite dev tools. Before I found Through the research I did related to that discussion, I read about the View Transitions API for the first time. And then when I discovered that SvelteKit had launched lifecycle hooks specifically to facilitate view transitions (even though they had already shipped support when I made this comment), this was the aha moment for me to undertake updating svelte-ionic-app to remove the awkward pieces that cause the most confusion, implementation headaches, and maintenance cost, such as IonNav and IonTabs. And it was only after I started that process, and began attempting to make sense of all the code in the repo, that I realized there were many parts I didn't expect, such as the create scripts, and that modularization may also benefit overall clarity. So, perhaps more important than the modularity of my project, or support for Svelte 5, is the fact that I don't intend to support Svelte without SvelteKit, which I've reflected in the name. Another important point is I aim to reduce areas of functional overlap between SvelteKit & Ionic framework, which means removing support for some Ionic framework features. Put differently, the parts of Ionic I value and aim to preserve are the UI components. However, Ionic doesn't define itself as just a UI component library. It would seem that it is the inclusion of additional features beyond the functional UI components, such as Navigation/Routing and Lifecycle is what makes Ionic a framework. I'd prefer if SvelteKit were the framework, and Ionic provided only the styled components layer. A good demonstration of this is Further responses inline below:
Partly answered above, but IonNav is removed and support for it is not planned. I would welcome a compelling argument in defense of IonNav, but the uses cases for it - Using NavLink instead of a router or Navigation within a Modal - seem like anti-patterns and should be avoided. IonPage is similarly part of the "framework" part of Ionic, and is made redundant by SvelteKit with view transitions.
See above. I would add that any framework component, even if designed to simply wrap the corresponding Ionic framework feature, nonetheless likely deviates from the Ionic API and introduces its own bugs, as well as requires nuanced explanation of the areas that are supported versus any that may not work as indicated according to the Ionic docs. This erodes confidence of potential adopters.
Absolutely agree. Every core UI component should be assumed to work exactly as designed in the Ionic documentation. I aim to create a 5th project, which would be documentation. The main objective would be to point out any deviations, with the assumption that if not explicitly called out it should work just like Ionic.
I agree with this in principal, and I think focusing the core package supports this aim. Though my focus on supporting SvelteKit and not supporting Ionic framework features, suggests this is unlikely.
By eliminating any svelte files from core, and from my use of your generator.js script to upgrade to the latest Ionic, this should be easy enough. Plus your addendum:
I already put forth my perspective on this, that SvelteKit is the most compelling aspect. Anyone who doesn't feel they need the additional features is free to omit them, and pays no penalty in doing so. But then, when the project grows to the point of requiring any 'Kit features, they are ready. This is exactly what is compelling to me about SvelteKit: that it supports any use case. Coming up with a way to support Svelte and SvelteKit separately would be possible. But it would require more complicated directions for which components would be supported and in what scenarios. I don't think this is worthwhile.
It's definitely part of a different, larger conversation, but I prefer Typescript. I disagree that JSDoc provides an equivalent DX. It's more verbose, harder to read, moves the context of types away from code where they're used, and is less intelligent or helpful. That said, when using the create CLI tool, if you specify JSDoc or no types, all Typescript references, ts files, and |
|
Hi @briznad, Thanks for your elaborate responses. What stands out for me is that you are speaking from experience working with Ionic and Svelte(Kit). And I like your thoughts about framework overlap between Svelte(Kit) and Ionic - there are some choices to be made here in order to make it more usable as a dev. And the ViewTransition api in Kit really is something that adds value, I agree. With your intention to make documentation you are creating room for a bit more specific opinion on how to best use it, which imho comes with using Ionic in Svelte(Kit) irrespective of which approach:
Looking back, I have mostly focused on trying to get the APIs exactly the same which hits a dead end road unless I want to do some really heavy coding such as building/tweaking routers (which the Ionic team has done for React/Vue and Angular). I think that also explain why I have not be maintaining the repo a lot - even though it still functions. Your feedback made me aware that achieving API-perfection bites true adoption here. The latter being way more important to me, as I equally feel very happy with both tools from a UX and DX perspective. So having said all this, I wonder what I should do moving forward with this repo. Do you propose to integrate this repo in your organisation? I would hate to give up the github stars :) Maybe it could become the core part, while embracing Kit? And then to your point have create scripts, components and documentation in a different spot. |
|
@Tommertom Where to go from here… that is the question. I wouldn't advocate for walking away from your stars. Seriously, you've earned them. I do think the However, none of that speaks to what the project focus or future should be. As for that, I still think it makes sense conceptually to maintain the goals you laid out in DISCUSSION - Rebuilding ionic-svelte #93, as well as "[making] it as if the Ionic team can take it over as is so official adoptions is as easy as possible for them." I took a look at @ionic/react, @ionic/angular, and @ionic/vue, and I wonder if there's room to modify your current approach to be structured more like those projects. In particular, is it possible to define all Ionic aspects - including IonNav, etc - using only js, and not using svelte files? Or put differently, is there a scenario where the ionic-svelte/core package was refined enough to become @ionic/svelte, aka have it officially handed off and supported by the Ionic team. That would seem to be a huge win. But obviously I have no idea if they would consider it. As it is, Vue is about 3.5 times more popular than Svelte, judging by weekly downloads, though the popularity on npm doesn't track with the popularity of each package within @Ionic (@ionic/angular is 2x as popular as @ionic/react, even though React is 10x more popular than @angular/core) so it's difficult to estimate what the popularity of an official @ionic/svelte integration might be, or what threshold Ionic/OutSystems to officially adopt it. Given the shifting tides for Ionic, this may be low on their priorities. But still seems like a worthy goal. The other thing I'd say for moving in this direction - not having svelte files - is it would eliminate the reason I created my project, which would be a good thing. I'd prefer not to split off my project. I don't want to create a competing vision for Ionic with Svelte, or steal away any of your stars :) Or even if I have a different vision for how someone may want to use Ionic with Svelte - aka using it with SvelteKit and not using the Ionic framework features - that's not in conflict with a simpler ionic-svelte project. Having ionic-sveltekit depend on ionic-svelte makes perfect sense to me. The only thing that prevents that is Svelte 5 support, which shouldn't be that difficult. I can take a crack at it. I could still see a world where my @ionic-sveltekit/components would be useful. |
|
@Tommertom and @briznad , thanks for this discussion. Very good points raised here. |
@gerhardcit It works :) There are many skeptics that will insist a hybrid web app bundled as native lacks sufficient rendering performance, but I believe that is largely untrue. For many use cases it's a great combination of tools: Svelte for logical composition of components, possibly with SvelteKit for routing, and Ionic to render UI components that will look natural/native on whichever mobile OS they're built for, and Capacitor to package it up with minimal time spent in XCode or Android Studio. As for "[is it or is it] not a SPA…?" It is definitely a SPA. The significance of |
|
To expand on @briznad 's perfect explanation, @gerhardcit - mostly on the Capacitor capabilities (lesser on Ionic UI): Josh Morony (an experienced Ionic vlogger) has demonstrated he can launch an app in the app store with just have one single simple HTML file that allows you to draw lines on a canvas - a few js lines in html. He used Capacitor for embedding the html in the native shell and that is that. https://www.youtube.com/watch?v=Y382mhVOoR8 I think as a principle apps published in the stores are client code heavy - which in web terms translates to SPA. And as you can build a SPA in Kit - it is totally doable and feasible. I haven't published anything in the store, but definitely succesfully deployed Kit-SPA apps on android devices (USB install) In theory you can actually have a SSR rendered app displayed in Capacitor - but a) without Ionic UI (as its custom components as per @briznad comment have their ways in handling hydration b) you cannot publish it in the app store as it won't have acceptable behaviour when offline - in capacitor.config you can specify a server URL the shell uses to load webcontents - normally localhost. Which brings me to something else really cool about Ionic-SvelteKit and Capacitor - you can do HMR in an emulator or even physical device with that same url parameter - which means you can build in web and immediately see the results in a device and even use native features. So that is really slick DX if you ask me. And even cooler - you can have live updates of the app without having to go through app store updates, using some capacitor plugin that pulls web assets and replaces them in the app.
In short on Ionic & Kit - my summary would be - Ionic UI works well with Svelte . As Kit has been setup to solve specific problems related to SPA (SEO, heavy JS, long time until interaction/meaningful paint/etc) many features it brings are not usable for an Ionic app - form enhancement and SSR notably are two things you need other solutions for (Superforms e..g.). But the router is very usable. If you need SEO, then I also wonder about why you would want Ionic UI at all - as native app look&feel imho are not natural for landing pages and other purposes that we find on the web. Each deployment technology has its own merits and purpose - full native, hybrid, PWA, SEO optimised web, you pick and choose what works for you best- ideally by trying. |
Steep learning curve on the org setup for me :) Will take a look at it.
I have spent quite some time tinkering on this and there are at least a few challenges to overcome:
Here I like to raise my earlier point - the more exact you want it to become to the Ionic API (and easy to handover to the team - if they would), the more work and possibly less maintainable it becomes. And my conversations with the Ionic team confirms that these parts (navigation and overlays) are the hardest part to maintain - making generic framework adoption a problem. This will be a hard design decision on their side - e.g. doing all animations with ViewTransition api only maybe?
I am not too worried about Outsystems support - I am inclined to believe they will continue the support, and maybe even more. My first goal was to drive adoption - getting Ionic people into Svelte and Svelte people into Ionic. Both had its merits and challenges. On the Ionic side (people coming from Angular/Vue/React) it is a framework conversation. On the Svelte side you see the largest developer base clinging onto the Kit perks that a SPA kinda-voids. I remember people literally frowning on me asking about custom componets in the Discord. Like I had some disease or something.... :) (not complaining here, btw) . Luckily the few interactions I had with the svelte maintainers (including Rich Harris) were infinitively more constructive, informative and enjoyable - and confirms everything: Kit is setup for non-SPA, customer component frameworks need SPA, hence always a tension. So I basically see now a new phase needed we just need something that works - with proven solutions for some of the challenges, not trying to be pixel perfect on native UI, nor religious about framework. That is where you come in, imho - you have something that works in reality and people can build upon it creating coolness -> ADOPTION!!!
So I would love to focus on the core support and documenting what we don't support in the core, for which we have the goodies you created. And then making you co-maintainer for the core, so there is less dependencies. I am very happy to take on Svelte5 support in the ionic-svelte package. |
|
@Tommertom on the topic of whether we could create a package that was closer to It's an alternative approach to the current |
I considered that as well, but imho it breaks the DX compared to how svelte loves to work with styling. Parent components cannot style the IonCard etc using ion-card selectors. You would then have to style everything in the global sheet, which goes against the style encapsulation principles that makes Svelte so appealing according to many. If you want to solve that, I suspect you have to pass css as props to the component which then programmatically needs to apply css props progammatically to the ionic element. That sounds pretty yuck to me. So to me a bit of a no here, unless it is something additional/alternative approach for those coming from React/Vue-land? But maybe you got to draw a line here... |
|
Those are great points. I didn’t consider the styling aspect. Oh well, back
to the drawing board…
…On Wed, Mar 26, 2025 at 3:36 PM Tommertom ***@***.***> wrote:
@Tommertom <https://github.com/Tommertom> on the topic of whether we
could create a package that was closer to @ionic/[react|angular|vue],
check out this repo I just put together:
https://github.com/briznad/ionic-svelte-wrappers
It's an alternative approach to the current ionic-svelte that downloads
the latest component definitions from
***@***.***/docs/core.json, then programmatically outputs
Svelte components with full type support for props. It handles IonNav &
similar previously difficult corner cases without creating Svelte files.
There are currently a couple issues - I need to fix event handling, this
outputs Svelte 4 and below syntax, I'd prefer to use a Svelte component
generator method - but I think it's pretty compelling as an approach that
is much more similar to how Ionic handles React, etc.
I considered that as well, but imho it breaks the DX compared to how
svelte loves to work with styling. Parent components cannot style the
IonCard etc using ion-card selectors. You would then have to style
everything in the global sheet, which goes against the style encapsulation
principles that makes Svelte so appealing according to many.
If you want to solve that, I suspect you have to pass css as props to the
component which then programmatically needs to apply css props
progammatically to the ionic element. That sounds pretty yuck to me.
So to me a bit of a no here, unless it is something additional/alternative
approach for those coming from React/Vue-land? But maybe you got to draw a
line here...
—
Reply to this email directly, view it on GitHub
<https://github.com/Tommertom/svelte-ionic-app/pull/111#issuecomment-2754859351>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTWNUB3A4SBCRODQJRKKD2WK3QNAVCNFSM6AAAAABZO2DFSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJUHA2TSMZVGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: Tommertom]*Tommertom* left a comment
(Tommertom/svelte-ionic-app#111)
<https://github.com/Tommertom/svelte-ionic-app/pull/111#issuecomment-2754859351>
@Tommertom <https://github.com/Tommertom> on the topic of whether we
could create a package that was closer to @ionic/[react|angular|vue],
check out this repo I just put together:
https://github.com/briznad/ionic-svelte-wrappers
It's an alternative approach to the current ionic-svelte that downloads
the latest component definitions from
***@***.***/docs/core.json, then programmatically outputs
Svelte components with full type support for props. It handles IonNav &
similar previously difficult corner cases without creating Svelte files.
There are currently a couple issues - I need to fix event handling, this
outputs Svelte 4 and below syntax, I'd prefer to use a Svelte component
generator method - but I think it's pretty compelling as an approach that
is much more similar to how Ionic handles React, etc.
I considered that as well, but imho it breaks the DX compared to how
svelte loves to work with styling. Parent components cannot style the
IonCard etc using ion-card selectors. You would then have to style
everything in the global sheet, which goes against the style encapsulation
principles that makes Svelte so appealing according to many.
If you want to solve that, I suspect you have to pass css as props to the
component which then programmatically needs to apply css props
progammatically to the ionic element. That sounds pretty yuck to me.
So to me a bit of a no here, unless it is something additional/alternative
approach for those coming from React/Vue-land? But maybe you got to draw a
line here...
—
Reply to this email directly, view it on GitHub
<https://github.com/Tommertom/svelte-ionic-app/pull/111#issuecomment-2754859351>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTWNUB3A4SBCRODQJRKKD2WK3QNAVCNFSM6AAAAABZO2DFSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJUHA2TSMZVGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@briznad - I am going to start working on your suggestions . I do believe your PR is pretty big and massive. So I want to cut things in chunks. Some other things
I am not sure if there is a better way to work with the PR, but at least this is what I would do |
|
Org https://github.com/ionic-svelte ionic-svelte created |
totally agree. to prevent any confusion, I didn't actually intend this PR as a suggestion that it should be merged. I just thought a PR was the easiest means to kick off the conversation. totally makes sense to keep the demo app and logo. I see that we're using the new org. very cool! I hope it wasn't too much of an administrative headache :) |
|
I'm going to close this PR. The conversation I was hoping to spur has been fruitful and I'm excited about the direction things are going. |
Hi @Tommertom
I wanted to inform you about a significant fork I've made to your
svelte-ionic-appproject. After using yoursvelte-ionicpackage for quite a while on many different projects, I decided to reorganize the code into more modular pieces, which I hope will allow each piece to be simpler. This version breaks out the core compatibility piece from the custom framework components, the CLI create tool, and the demo app. Also, all Svelte code now uses 5+ syntax. I've created distinct repos/packages, and have grouped them under an organization in GitHub (https://github.com/ionic-sveltekit) and NPM (https://www.npmjs.com/org/ionic-sveltekit). The various pieces are now:the essential compat layer exposing Ionic custom components
custom Svelte framework components that use Ionic custom elements and can be imported into Ionic SvelteKit apps. This includes a Tabs component, which we've discussed previously, as well as a Tooltip component.
A demo app, showing how to integrate various Svelte features and Ionic UI elements. This is used as the base demo app when creating a fresh project via CLI tool.
The CLI tool to spin up a new Ionic SvelteKit app.
I would love for you to take a look and provide any feedback you may have. Additionally, I want to say thank you. As I point out in the updated README, you deserve immense credit for this tool, and all of my recent work on this update is still based on your prior toil. I'd also like to offer for you to be a member of this new org and maintainer.
Let me know what you think.
Thanks,
@briznad