Proposal: Starter Kits and Integration Testing #82
Comments
|
Hey @siguici! I completely agree. I have been recently holding off on merging changes that would affect the build for this exact reason. Automatic VersioningI will be talking to Shai Reznik from the Qwik core team this week and he will help us set up changesets and automatic versioning. (DONE) Also not sure if I will get to this with him, but setting up experimental snapshot versions, so we can test changes before releasing. TestingWe switched from cypress to playwright in Qwik UI, and have found it to be more productive and robust. In particular I think it would need to be testing the preview environment for most tests, as in dev there is no javascript streaming. If you'd prefer a particular tool happy to discuss it here. Something to mention, is we have this issue with vitest: I initially thought the problem was with Qwik City as a vite plugin, but after looking through the code I'm not so sure. I'll have to bring this up with the core team, as it's related to the Starter KitsOne I could think of would be setting up either eslint (+ prettier) or biome for them, along with the tsconfig. The problem we have with biome currently, is there isn't a plugin system, and so On the other hand, the last time we tried adding eslint here, it doubled the build time. If we have to choose between that tradeoff, biome would likely be preferred. I know at some point, I am looking to make a PR to the Astro CLI in Astro core in order to add the tsconfig automatically via the CLI for 3rd party integrations. The CLI code is a bit, overwhelming 😅 . DocsWe are getting to the point that the README file is getting a bit too long 😬 . At some point, I would like to set up a docs site (maybe using starlight!) with relevant information about the integration, including some Qwik component examples.
MaintainersUp until this point, I have been solely maintaining the project (ability to merge PR's). This integration is part of the official I would love to chat with you over voice sometime this week if you're free! It's really exciting that the integration is organically growing, even when I have not mentioned or posted about it. I think JavaScript streaming and automatic optimization solves many problems current Astro users have today. Really excited that we can push the web forward here 😄 |
|
@iivvaannxx would love to hear your thoughts |
|
Glad to see the project expanding. Kudos to you guys, you're doing a fantastic job. It's heartening to witness the evolution of the Web and even the Internet in general 🚀, thanks to people like you. 👏 I also use Playwright in most of the projects I develop, and I find it simply awesome. I'd be delighted to collaborate with you on integrating this tool. 😊 Regarding the starter kits, I think it would be best to use Prettier, as Astro and Qwik use it internally, and to incorporate Biome into this project (if I'm not mistaken, this is what Astro does). I can assist with integrating command-line templates. 💻 Oh, and I also use Starlight for documentation 📚, and I find it super cool and user-friendly. I'm totally up for helping you out in that regard. ✨ I'm open to discussion, and it'll be a pleasure for me to engage with you. 😊 Indeed, I've noticed that you're the sole maintainer of the project, and it's quite challenging given the scale of this project, which brings together two major ecosystems. Best of luck to you. You can count on me to help advance the project. 💪🙌 |
|
Excited to announce a starter kit for @QwikDev/astro and Deno! 🚀 This starter kit, inspired by @Mac-Mann's request in #75 (comment) and the proposals mentioned in this issue, is now available to help kickstart your projects more easily. You can find the starter kit here. I've also created a simple logo that I'm using as the favicon for the project, which is also available in the repository. If you find it appealing, we can consider using it for this project. Feel free to check it out at qwik-astro.deno.dev, and I'm open to any discussions on possible improvements or integrations into @QwikDev/astro. Whether you're new to these technologies or looking for a more efficient way to start your project, this starter kit is designed to help you move forward quickly. Happy coding! 🌟 |
Haha everytime I see a comment from you @siguici I get super excited 😄 . Today I will talk with Shai to setup snapshot releases. My discord username is Something to mention, changesets are now working automatically! Happy to show how it works over voice 💪 Also the monorepo scripts are now working. For example, Could do the same with deno. Will set the rest of that up today. |
AMAZING. Let me go add it to the project readme 😄 . |
|
Hey there, @thejackshelton and @siguici! I really like the proposal too, and you can count on my support! My only issue is that for the next couple of weeks, I'll be wrapping up some personal projects that need my attention (one of them includes a website using this plugin 😆), so I'd prefer to not take on anything else until those are completed to keep my focus. However, I'll still be keeping an eye out and am open to discussing any details! Feel free to tag me if you need anything, and I'll get in touch! I've also worked with Playwright and Starlight, so I'm familiar with those tools and find them very suitable for our needs. An idea that crossed my mind is whether it's possible to make this integration "official." I believe official integrations like those for Svelte, React, and others are maintained by either the Astro community or the Astro core team (though I'm not entirely sure about this). I'm curious about what this would imply:
I consider Qwik to be quite an important framework that could stand alongside the more popular ones. By making the integration official, it could gain more support and reach more developers! Possibly, we could even feature this integration in the official Astro docs (building on @thejackshelton's idea of making a separate docs site), just like the other frameworks supported by Astro. I'm not certain if this is just a possibility or something we can pursue, but the integration has become much more mature since I first stumbled upon it, and I feel it could be feasible. EDIT: It seems that all the official framework integrations are maintained by the Astro Core Team, so this probably couldn't be done, still would like to hear your thoughts on it though! |
|
Hi everyone! @thejackshelton, @iivvaannxx, I hope you're all doing well. It's truly gratifying to receive positive feedback from you. I'm thrilled to learn that we share the same interests. I volunteer to create documentation using Starlight, starter kits for users, and support for other runtimes and testing/integration tools as mentioned by @thejackshelton #75 (comment). Regarding the idea of templates and making them official, I fully agree with @iivvaannxx. I'll explore Astro to streamline integration from the command line. As for the length of the README.md, I believe we can utilize Wikis temporarily until the documentation is ready. I'll start working on the starter kits and documentation tonight. I'll make a PR in the coming hours. I'm also considering the use of Playwright, but that will come later. @thejackshelton, I've left you a note on Discord. |
|
I've just submitted the template to the Astro website (https://astro.build/themes/). Once approved, it will be available at https://astro.build/themes/details/qwikdevastro-deno/. |
I think the README is a good enough interim for now, and then once we roll out the docs, we can simplify the readme, and refer to the docs in certain areas. Also having the docs in the project bio. @siguici I don't seem to have gotten a message. What's your discord username? |
|
OK @thejackshelton. I'll add the website to the repository so it can be deployed on GitHub Pages (https://qwikdev.github.io/astro) or on Read the Docs while we reserve a domain name, etc. I use the same username (siguici) everywhere. It's the same for Twitter and Discord. |
@siguici adding starlight to the repo would be great! I'll set us up with cloudflare rather than github pages. We could use the Astro cloudflare adapter and still use node as a static site. Has automatic deployments setup for us, preview environment, no bandwidth limitations, etc. |
|
Also @siguici I haven't been getting any notifications on discord, but I went ahead and sent you a DM via Twitter 👍 |
|
Sounds good @thejackshelton, I'll proceed with adding the website. I had initially thought of placing it in a directory at the root of the project, but I've instead opted for the apps/ directory since that's the one you chose for QwikUI. I've just left you a reply. |
No worries at all @iivvaannxx! I have multiple client projects on the integration as well haha. Here's a bit of background on how I got into this problem space, as a bit of context to my thoughts on whether Qwik should be a first party integration.
Some backgroundThe Qwik Astro integration is part of a year and a half long quest to automatically optimize the interactive pieces in the sites I was building. I came to Astro from WordPress Dev around mid 2022, and really enjoyed the minimal and opt-in nature of Astro. The biggest problem I had though, was once you opted into something like React, even with Astro or even Solid & Preact, it's not all that minimal anymore as you add more features, and when moving fast, it also contributed to the bloat of the page. Swiper JS, shadcn, google tag manager, embeds you name it haha, whatever solves the problem (and Astro does that great!) In fact, I never even had heard of Qwik at the time. I spent many months experimenting with React, Solid, Vite, Astro's hydration directives, etc. Although despite all this effort, it seemed like no matter what I added, the benefits weren't fully automatic. Many things still felt very manual and time consuming. Not only was this a problem I felt just couldn't be solved, it seemed like all of the newer alternatives were moving towards a manual approach. An example of that being RSC's, and the use of serialization and directives to make a client-first framework get the benefits of the server. And so early 2023, I had reached out to the Qwik team about the possibility of using Astro in Qwik. I was told that "Astro is bound by hydration", and that Qwik City will be their main and only focus as a meta-framework. And so I left it at that until chatting with Misko later last year, and I learned that it wasn't bound by hydration at all. And I got the go ahead to start it (misko even helped a bit which was awesome!) What differentiates Qwik from other renderers in Astro?It's at this point, that it's very self evident there is a problem that needed to be solved here. (recently, even the Angular team has realized that! They are trying to gain the ability to delay the eager execution of code) In fact, looking back on it, we needed two things:
I realized that this is not possible in other renderers without resumability as a prerequisite, it is also a massive breaking change to the entire framework's ecosystem, and so it is not likely to be supported in another framework anytime soon. If you imagine a video streaming analogy, when you upload a video to YouTube, they are in charge of the video streaming (and automatically chunking that video into tiny packets). Qwik works much like video streaming, but with JavaScript. For example, here's a mini demo I had made a month or so ago. The initial JS executed is from Astro's view transitions. The PracticalityI would argue that most Astro sites want this behavior. Your components are html until your user actually opts-in with the interactive pieces. This fits very well into Astro's opt-in nature. Why should you execute a carousel if the site visitor never interacts with it? Or execute the footer animation when your user is at the top of the page? Most developers also don't want to worry about any of this stuff! They just want to build their app. Automatic optimization benefits both the developer experience, AND the user experience. Being able to sprinkle in as much interactivity as possible, without compromising on the performance, or the developer experience. In my case, I also wanted to be able to use Astro's amazing features, such as Astro DB, Content collections, View transitions, and all of the many amazing goodies that the Astro team has pushed forward.
Finally answering the question below haha. |
ThoughtsYes, I think it would be a major hit to the Astro ecosystem to not have Qwik as a first party integration. It aligns the most with Astro's core principles as a framework. I reached out to the Astro team about the possibility when the integration was much younger, and IIRC, was told that core integrations are those maintained by the Astro core team. I completely understand, and at the time if I (hypothetically) had to step away from the project, the Astro core team would not know how to maintain the Qwik side of things. Which I will say here and now that the integration is a major part of my work, and I'm even currently developing with it on my portfolio. Concerns & SimilaritiesHowever, this also goes both ways. Qwik is a renderer inside of Astro, and is now a critical part in a decent bit of Astro projects. Astro intends to be UI agnostic. By this principle, a renderer is at least partly a concern of Astro core. If changes are made with assumptions to those of only the official renderers, it is going to lead to an uphill battle of maintenance and compatibility issues. (not UI agnostic) An example of this, would be changes made affecting all renderers with the assumption of hydration. Another principle of Astro is being fast by default: Less client-side JavaScript to slow your site down. While this is true, I believe the majority of Astro sites use a renderer, and once you have opted into a framework, you have added the runtime cost at the very least as soon as your visitor gets to the page. Now Qwik is not Zero JS by default, it uses the Qwikloader a 1kb minified and inlined script tag, but what is much more important here is the amount of JavaScript added on the client as it grows. Qwik is O(1) constant the more components you add. Qwik core also is inline with Astro's server-first principle. You can choose whether or not you want something to execute on the server or the client. This makes it really adaptable with your Astro components, and On another note, there have been times Astro community members mention the exact problems the Qwik integration solves, and are unaware the integration's existence. Regardless, I still try my best to reach out directly. I initially proposed a community renderers section that is easily navigable in the docs. It is currently in the integrations page as a renderer. Technical Aspect
I can't say for certain what exactly would happen, but I definitely think it should be discussed first before making any major changes. Some ideas would be:
Pure speculation here, but in the case that it were to be an official package, I believe it would be a breaking change. A package name of But either way, I want to make it clear that my commitment to the project remains the same 😄 . I am very passionate about Astro, and I think it deserves a well-maintained server first UI framework that is cohesive with many of its underlying principles. This integration was also possible with the help of the Astro core team! If it weren't for nate, matthew, and arsh who knows how far along the integration would be 😅 . |
|
What an amazing and clear explanation of the situation @thejackshelton! I understand the big picture much better now, and even if making the integration official wouldn't be possible in the coming future I find such a great idea that section of "community renderers" you talked about. This integration would make a great fit in there! Once this integration becomes even more mature (fixing the currently opened issues, and better implementing these starter kits which are being discussed here) we can try to pursue that so we make this project reach even more Astro developers. |
Sounds good! Once that's added to the repo, I'll go ahead and deploy it to cloudflare. Also responded 👍 |
|
Thank you, @thejackshelton, for sharing your insights on the potential for an official integration so thoughtfully. I'm genuinely thrilled about the momentum we're witnessing here. The synergy between Astro and Qwik seems promising and has the potential to benefit a wide audience. I will try to contribute some stuff soon 😄 |
|
Thank you, @thejackshelton, for these impressively clear explanations. I remember the very beginning of Qwik, I immediately connected with the idea of resumability. It's actually the lack of this feature in frontend frameworks that made me hesitant to use them. Today, I integrate Qwik and Astro into most of my projects, aiming for better UX and DX. The week I saw the announcement of Qwik integrated into Astro, I thought to myself, 'this is some crazy stuff.' It was exactly what I was looking for, and right on time. In that same week, I was wondering if it was possible to use Qwik without Qwik City and how to integrate it into other projects using it as a rendering engine. That's when I started following this project closely and delving into the source codes of these different projects to understand their internal workings better and how we can extend them. It's always a pleasure for me to add my two cents, and I appreciate the scale this project is reaching. It would be great if it were directly integrated into Astro, but until that happens, we can give it a big push. I actually plan to take inspiration from Astro's CLI to propose adding the Thank you, @magnusmay, for your support. I think your contribution will be of great help. |
|
Closing this issue since it's completed 😄 |
Enhancing Project Usability and Developer Experience
Given the expanding scope of this project, I propose initiatives to improve its usability for both users and developers.
Starter Kits:
Inspired by those in Qwik and Astro, let's develop one (or more) starter kit(s) to streamline project creation.
Integration Testing:
By adding integration tests with tools like Playwright or Cypress, we can ensure library reliability, enhancing the developer experience.
These efforts aim to streamline project setup and bolster reliability, benefiting both users and developers.
Objectives:
Tasks:
Your feedback and suggestions on these proposals are welcomed as we work together to enhance project usability and developer experience.
The text was updated successfully, but these errors were encountered: