-
|
Hello to all my friends :) I have some important and weighty things to discuss. TLDR: I’m proposing to pivot Blitz to a framework agnostic toolkit that preserves the world-class DX and features we adore but brings it to all Next.js users and optionally Remix, SvelteKit, Nuxt, etc. I’ve been taking stock of where we are with Blitz and of what we’ve accomplished in the almost 2 year journey together. What we have done is incredible. We invented a fullstack developer experience that is unmatched, enabled by our zero-API RPC data layer. So many tell us it makes them 5-10x more productive 🤯 Nearly 100,000 Blitz projects have been created. No doubt many of those are throwaway tests, but still, that's a ton!! We recently passed the 10,000 Github Stars milestone that so few reach. Our community has grown to 2,500 Discord members and is absolutely incredible. We’ve had almost zero negative incidents. Everyone is so kind and generous. We’ve also achieved incredible awareness. Tons of people are really impressed with what we’ve made. But at the end of the day, 99% go back to Next.js to build their production apps. The reality is that we are, and always will, play second fiddle to Next.js. And so sadly, 99% of people never get to benefit from what we've built. Growth has totally stagnated this year. Our weekly npm downloads is a perfectly flat line this year with around 5,000/week meanwhile Next.js downloads are growing exponentially and is now at 2.2 million per week. When we made the decision to fork Next.js, I expected that Blitz would start to carve out a small portion of Next.js users. But that absolutely hasn't happened. In fact, I think the fork has actually hurt adoption. That said, I still feel trying the fork was the right decision. I have a way better vision for what a Blitz toolkit should be now than I did then.
The Next.js fork has nearly killed our feature momentum. And we are no longer executing on the vision we set out to solve. Instead we spend so much time spinning our wheels fixing weird package manager things, keeping up with nextjs changes (we have no inside knowledge of nextjs plans), etc. Lack of momentum and lack of growth really hampers our motivation. At the end of the day, I can't see anything that would significantly change our growth trajectory without a pivot. If we’re always going to play second fiddle to Next.js, the best solution is to find another instrument no one is already playing :) ProposalFirst let me say that the thought of not having Blitz is terrifying. I’m building the Flightcontrol dashboard with it, and I can’t imagine having to do it all from scratch without the Blitz DX. And I know I'm not alone in this. Many of you have told me the massive impact it has had on the productivity at your companies, your ability to hire and onboard developers, etc. So whatever would come next, it absolutely must preserve the DX and huge productivity wins that current Blitz has. Objectives
Therefore I’m proposing to pivot Blitz to a framework agnostic toolkit that preserves the world-class DX and features we adore but brings it to all Next.js users and optionally Remix, SvelteKit, Nuxt, etc. A toolkit for building anything with a database, from side projects to massive enterprise apps. A toolkit that both enhances fullstack DX and provides the missing backend components for JS that Rails and Laravel enjoy. Keep reading, I flesh out the vision more below. Trust & TransitionI really care about you all, the time and effort you’ve invested into Blitz, and your involvement in the community. It’s been a super fun journey, and we’ve come a long ways. But I truly feel we have reached the peak. I don’t see any possible way to go from here to the future we imagined and dreamed of, without a significant change. It’s time to face some realities and decide what is best for us all You all have put incredible trust in me, building many thousands of production apps on an alpha and then beta status framework. So I feel a heavy responsibility to not damage that. You have my word that, should we choose to pivot, I will do everything we can to make for a smooth transition from current Blitz to Next.js + Blitz Toolkit. This means preserving APIs as much as possible and heavy reliance on codemods to automate almost all changes including renaming imports from It would be very sad to lose Blitz as we currently know it (I’ve shed some tears). But many times in life we have to make difficult decisions to lose some things in order to gain even greater things. I’ve already discussed this privately with a sampling of folks from our community, and all of them have basically been like “yeah it would suck to have some sort of migration, it would be sad to lose what we have, but also it makes sense that this would be the best for us.” What The New Blitz Toolkit Could Look LikeThe New Future, Features, and PossibilitiesI originally set out to make the Ruby on Rails equivalent for Javascript and React. But I’m now of the opinion that the surface area for something like this is too massive for one framework to do well. Using a JS UI library like React or Vue adds so much more complexity to the problem. Complexity that Rails and Laravel knowing smirk :) However, I want to give huge props to RedwoodJS. They have done a way better job at executing on that very Rails-y flavor, at least in part because they've built everything from scratch. They also had ~1 year head start. If we take a look at the entire JS ecosystem, most of the money and effort is going into frontend frameworks, but very little into backend functionality like queues, cron jobs, etc. There are Nestjs and Adonis, but they aren’t exactly designed to work with frameworks like Next.js/Nuxt/Remix. This means there’s a huge opportunity for us to provide all of the backend features that Rails and Laravel enjoy, and do it in a way that all JS frameworks will love. It was always my intention to build these features for Blitz, but got bogged down too much to get to them. My vision for the new thing is an enterprise-ready fullstack toolkit with an emphasis on backend components. Blitz would be a DX booster pack you can add to anything to ship faster and have more fun. FeaturesI believe the core value that Blitz currently provides is 1) the zero-api data layer, 2) authentication, 3) authorization, 4) conventions, 5) new app templates & code scaffolding. A new toolkit would start with these as the foundation. I think almost everything Blitz currently adds would be migrated to the toolkit including recipes, typesafe Routes manifest, etc. Then we’d start shipping a ton more awesome things. Here’s the features I want to build. And all them would be standalone modules that you can use independent of the others.
New Zero-API Data Layer Setup
Server setup file // blitz.server.ts
import { setupServer, sessionMiddleware } from "@blitzjs/next"
// queries/mutations folders are no longer "magic".
// You know have to explicitly import into this setup file
import createProject from "app/projects/mutations/createProject"
import updateProject from "app/projects/mutations/updateProject"
// You can now have multiple resolvers in a single file
import * as projectQueries from "app/projects/queries"
// api, gSSP, gSP will be used to wrap everything for auth and middleware
export const { api, gSSP, gSP, Server } = setupServer({
middleware: [sessionMiddleware],
queries: {
...projectQueries,
},
mutations: {
createProject,
updateProject,
deleteProject,
},
})
export type Server = typeof ServerExpose your server in an API route // pages/api/rpc/[...path].ts
export { Server as default } from "blitz.server";Client setup file // blitz.client.ts
import { setupClient, clientSessionMiddleware } from "@blitzjs/next";
import type { Server } from "./blitz.server";
export const {
useQuery,
useQueries,
useInfiniteQuery,
useMutation,
queryClient,
BlitzProvider,
} = setupClient<Server>({
middleware: [clientSessionMiddleware],
})Using Queries/Mutations on Client // some component or page
import {useQuery, useMutation} from 'blitz.client'
// Option 1 (strongly typed)
const [project] = useQuery.getProject({ id: 1 });
cosnt [createProjectMutation] = useMutation.createProject()
// Option 2 (also strongly typed)
const [project] = useQuery("getProject", { id: 1 });
cosnt [createProjectMutation] = useMutation('createProject')Wrap getServerSideProps // pages/ssr.tsx
import {gSSP} from 'blitz.server'
import getProject from 'app/project/queries/getProject'
// fully typed automatically
export const getServerSideProps = gSSP(async ({req, res, ctx}) => {
// access session
ctx.session.userId
// Directly call query fn, pass `ctx` through
const project = getProject({id: 1}, ctx)
return {
props: {}
}
})Wrap getStaticProps // pages/static.tsx
import {gSP} from 'blitz.server'
import getProject from 'app/project/queries/getProject'
// fully typed automatically
export const getStaticProps = gSP(async ({queryClient}) => {
// Easily prefetch query to fill client side cache
await queryClient.prefetchQuery('getProject', {id: 1})
return {props: {}}
})Wrap API routes // pages/api/hello.ts
import {api} from 'blitz.server'
import {trackEvent} from 'app/events/mutations'
const handler = api((req, res, ctx) => {
// access ctx and session
ctx.session.$authorize()
// Call query/mutation directly, pass ctx through
await trackEvent('api', ctx)
res.statusCode = 200
res.setHeader("Content-Type", "application/json")
res.end(JSON.stringify({ name: "Secured Agent" }))
})
export default handlerCons
Pros
Few Misc Notes
So What Now?DecisionFirst thing is to get all your feedback and make a decision on whether to move forward with this or not. Aiming to make a decision next week. We can also spawn off other RFC discussions to discuss feature and API specifics. Building The New Blitz ToolkitIf we move forward, there’s different paths to take, but I think the best is for Aleksandra and I to pause any new work on existing Blitz and focusing on shipping new Blitz Toolkit in January. At which point people could start building new apps with it or manually migrating existing Blitz apps. Then finish codemods etc that are needed to automate migrations as much as possible for everyone else. I would petition the Next.js team with all my might to accept as many of the current Blitz-only features as possible like app env loading with Status of Current BlitzYour existing Blitz apps will continue to run as they always have, and we will fix any critical bugs the come up. The current blitz codebase will remain. It may move to a different repo, but it will be preserved and we can continue to make releases as needed. Your FeedbackI know this is a big deal and has a big effect on all of us. You are probably feeling a number of emotions right now. So I invite you to avoid a knee-jerk reaction, take a little time to process it, and then please share your perspective on what we should do. 💜 |
Beta Was this translation helpful? Give feedback.
Replies: 62 comments 101 replies
-
|
A) Thanks so much for the honesty! I really love the product you made and feel confident that your future contributions (technological and cultural ) will help transform the Javascript ecosystem for the better. B) I'm fairly new to blitz ( 2 years developing as a whole ), but I just spent two months on a project that we were about to deploy (it's not a continual improvement thing, it's just done). Should I be putting effort into converting it to a NextJS project for future maintainability before delivering this product, or should I be good to deploy it as is? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I would definitely deploy as is. We'll make the transition way easier if you wait a bit for us to develop those tools. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for putting in much work all these years to create a beast tool for us all. I came from NextJS because I had an issue with the server-side in production and I started looking at other frameworks and I saw blitz. It's been 3 weeks since I started using Blitz and I have been able to move my project to Blitz seamlessly. I have had my fair share of the stress working with another framework but it's really helped me a lot. I have moved both backend and frontend to Blitz without regret and I will feel sad if this wonderful framework goes away. I totally understand the stress that comes with maintaining this framework and how frustrating it can be when you create a tool and lots of people don't use it. I am doing my best as a developer who loves Blitz to promote Blitz to my peers and also make sure we use this framework in our next project at the office. I will feel very sad to move back to NextJS, to be honest. |
Beta Was this translation helpful? Give feedback.
-
|
-- major sigh of relief --- Again thanks so much for the whole framework in general! I had a blast working on this project. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly everyone takes a risk using such a new framework but we all knew. I found out blitzJS while creating a website so I had to move all the nextJS project to blitzJS. I literally took me 2 weeks to do what it would have done in probably months with a lot of things to manage. Web development is constantly evolving, today the most used JS frontend framework is NextJS but I see a future for Svelte and probably there will be also a new one soon. I think that having an independent toolkit is the right path to take and take this project to the next level. |
Beta Was this translation helpful? Give feedback.
-
|
At first I was sad. Now this makes total sense. Currently prisma is the default orm for blitz. Would this continue being the case? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, Prisma is incredible |
Beta Was this translation helpful? Give feedback.
-
|
We could alternatively have Objection which is based on Knex. |
Beta Was this translation helpful? Give feedback.
-
|
How about using Vite? I believe Vite is the future. Not only is it a very well-designed piece of Software but also a welcoming community. I've got to know the Vite folks while contributing to the Vite ecosystem and they are lovely people 😊. |
Beta Was this translation helpful? Give feedback.
-
|
Vite is a build tool, not a framework, right? We would need to pick a build tool for the new toolkit package development — am looking at Vite as an option. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, Vite is comparable to Webpack but way, way faster and more ESM compatible. Snowpack was its main competitor but that project is essentially dead now that all the frameworks that were using it have migrated to Vite. |
Beta Was this translation helpful? Give feedback.
-
|
+1 on vite |
Beta Was this translation helpful? Give feedback.
-
|
Vite is powerful and could greatly reduce the build and HMR times on the new blitz kit! |
Beta Was this translation helpful? Give feedback.
-
|
In Parcel you don't have to worry about CJS or ESM modules. The code just works the way it is. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @flybayer, I appreciate the detailed write-up. A few months ago I decided to use blitz as the production framework for a new product I'm building. It's large codebase, it was a bit of a risk (with it not being at 1.0), but I was so compelled by the design decisions + community, that I took a chance on it. I had a slight recoil to the announcement, but in reflection, I think this is a strong move. And, I really respect the transparency and fortitude to suggest such a large pivot (especially so close to 1.0!). I'm not excited about a migration, but I'm happy to do it to be back on the nextjs release path as well as take advantage of the compelling feature list that you specify above. I'm pulling together various tools to accomplish many of the things that Blitz does not, I would love for things like queueing, mailers, etc. to be out-of-the-box. I'm confident continuing to deploy with Blitz in its current state. I'd love to punt on a migration until Q2 of next year, so would be greatly indebted to y'all for staying up with critical fixes in the meantime. I'll be starting a monthly contribution! Pausing on feature releases makes sense. Please let the community know where involvement / contribution could be helpful -- I'd love to take part. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the honest post @flybayer I am in the same boat here. We have blitz in quite a large codebase w/ a medium-sized team, and we knew it was a risk too - but we took the word of "there is a 1.0 coming in 1 month.." which has been constantly pushed back, although blitz has remained fairly stable we did take a large gamble ourselves here. Using blitz allowed me to build an application in 1-2 weeks that would usually take 1-2 months. If anything, a move to this toolkit should increase the development speed for developers using it and provide an even better DX otherwise it really does not seem worthwhile. Side note, the DX does seem a little "odd" in the new spec.. I don't mind the additional server and client files, however having to specify all the existing queries and mutations in the blitz server, and the additional wrappers seem to counter the DX that blitz was striving for. One of the things that made blitz so fantastic was the "magic" it provided, to remove the magic (e.g. require wrappers, forced file path structures, specifying every query and mutation in a list, etc) would increase developers time in a project. |
Beta Was this translation helpful? Give feedback.
-
|
The query and mutation issue may have been solved: #3083 (comment) |
Beta Was this translation helpful? Give feedback.
-
I am 💯% on board with this ideaI agree with the premise of this proposal, blitz has grown into something that is very difficult to track and contribute to. I have been recently drawn to Remix, so I love the idea that going in that direction doesn't have to mean ditching Blitz. Plus it's great for Blitz to have such a clearly defined scope going forward. The foundational change in scope here is that Blitz can defer to the best practices and guidelines of your chosen host framework instead of trying to reinvent the wheel on everything. Some implications of this that I want to call attention to:
The main drawback to losing this is when you run a recipe that adds multiple pages/queries/mutations/utility files it was nice to have a single folder you could delete if you wanted to not use that recipe anymore vs having to find all the individual files it created. But that's a relatively minor complaint, overall getting rid of this will simplify matters for blitz.
Right now Blitz asks you which form library you want to use immediately when you create a new project. That always struck me as bad timing/a trick question. Possibly the user doesn't know what form library they should use and so they just have to guess. With this proposal, you can stick with whatever the host framework recommends for you. If you are doing Blitz + Remix, then the best form option is Remix's
It feels like there ought to be a default convention or DSL (probably tailored to the host framework) that I could work from, without having to manually register every query and mutation. Sort of like |
Beta Was this translation helpful? Give feedback.
-
Personally, I really like it |
Beta Was this translation helpful? Give feedback.
-
|
I personally also really like to group my project into domains, and put everything related there. In that regard, Blitz is doing a marvelous job! |
Beta Was this translation helpful? Give feedback.
-
This is something quite important to us and has allowed to us to keep concerns properly separated. It was actually one of the original reasons I looked at blitz.
It's not a killer thing, but I do think you could add a babel/swc handler to automatically scan in and add it all on build time or something like that.
I don't think it's worthwhile to lose DX just to support a new framework. Remix should expose something, I'm sure if a proposal was made they'd open that up. |
Beta Was this translation helpful? Give feedback.
-
To be honest. I don't know why people are so excited about using other libraries. Remix is just too new and doesn't have much to offer over NextJS. Nuxt is terribad. Vue is awful. I know because I've used them both in anger to create projects. NextJS/React is so much better. Svelte's ecosystem is just too small right now. Basically, good luck trying to push into prod an enterprise app not built in React. |
Beta Was this translation helpful? Give feedback.
-
I don't understand either how Remix suddenly became a go to library for people in such a short period of time but maybe they're confident about the power of advertising it's benefiting from with big frontend names being behind it. For Vue I also prefer the React way of doing things but it still seems to be pretty popular + alternative to trillion dollars company's frameworks, so it'a understandable. |
Beta Was this translation helpful? Give feedback.
-
|
👋 Happy to work with you to understand changes that could be pushed upstream to Next.js from the Blitz fork. This was well-written and very clear, kudos 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, I appreciate it! |
Beta Was this translation helpful? Give feedback.
-
|
👏 Congrats on having the guts to see this situation and make this post. Couldn't have been easy. My thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding your last 2 points: the new zero-api layer will absolutely be compiler-free, similar to trpc. So that allows us to work seamlessly with any framework regardless of their build tooling. I took a hard look at using trpc for the new thing, but it's too far away from the DX we currently have (and will have) to use it directly. |
Beta Was this translation helpful? Give feedback.
-
|
Before I got to know Blitz, I was setting up exactly what Blitz would do for me. So I had my prisma server and nextjs app just about ready in order to build the app. Then I got to know about Blitz and my development experience and productivity drastically picked up. Blitz encompasses exactly these best practices I love in Prisma and Next, and the glue that connects it. I'd be sad to see Blitz lose its focus on what made me move to React and all its related tooling. At the same time I can understand wanting to break free from the dependency hell you have built. However I fear you are plunging yourself into the next hell. |
Beta Was this translation helpful? Give feedback.
-
|
@MartinMuzatko the vision and features that attracted you will totally remain and exist in the new toolkit. The only difference is a bit more explicitness (bit less magic) and using next apis directly instead of all wrapped by Blitz. But nothing will change with the glue that connects Prisma to Next. |
Beta Was this translation helpful? Give feedback.
-
|
Hey! I understand where you are coming from. Competing with a powerhouse like Next (especially when Vercel seem to be hiring half of the best react talent out there at the moment) is daunting so I respect the reason you are looking to do this. Although I probably don't have much use for the toolkits proposed features right now - I have tried to work with some of this stuff in a previous role and it was a nightmare, so it would be cool to see what the blitz team can do in this space. I am not as happy about this as other people seem to be - but I understand the reasonings, and that will have to do for now :D |
Beta Was this translation helpful? Give feedback.
-
|
Based on this:
It sounds like if people wanted to continue maintaining and building on the current codebase that will be an option. |
Beta Was this translation helpful? Give feedback.
-
|
@Swapnull thank you for sharing this — I totally get it. It's folks like yourself that I have in mind for developing the migration tooling. I'm hoping that you'll be pleasantly surprised at how seamless it will be. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I think you may misunderstand what I said (on re-reading, it wasn't phrased the best). The project I am building has 4000h of time into it, and it is build using blitz - not 4000h contributing to blitz. I imagine some of the team have put about that, if not more, into building and maintaining blitz though. To explain the 4000h. It comes to 100 work weeks. I have a team of 3 and we started working on our blitz project in Feb, so about 48 weeks ago. To be clear, the more I look around the ecosystem, the more this new framework makes complete sense to me 🙏 Can't wait to try it out! |
Beta Was this translation helpful? Give feedback.
-
|
I love this proposal, especially the plan to possibly support frameworks other than Next.js. In light of that, I recommend you do everything you can to make this backend-agnostic. In Remix especially, some folks deploy to Cloudflare Workers, and they'll soon support Deno. Supporting those non-Node.js runtimes will even more important as time goes on and more compute happens at the edge. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that was already my plan :) |
Beta Was this translation helpful? Give feedback.
-
|
Oh! Just to be clear, do we refer to some kind to runtime agnostic compatibility? Or “backend agnostic” per se? I’m a bit confused 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
By "backend-agnostic" I think he means "runtime-agnostic". I.e. aim to work with Deno, cloudflare workers, etc, not just Node. |
Beta Was this translation helpful? Give feedback.
-
|
Got it! Thanks 😊 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @flybayer, I'd like first to thank you and the rest of contributors for your dedication to this project and also I appreciate the chance you give us to participate in this discussion. I'd try to focus on these two paragraphs. Forgive me if my English is not too good.
I'd like to tell you why I decided to choose Blitz. I started a project using NextJS but after some weeks I started to struggle with documentation and I found that some things like authentication, convention about project structure... were not there. Then I started to look for an alternative, and I saw Blitz, but you know what? I didn't choose Blitz mainly because I saw "It's on beta". I know that it's silly but I wasn't sure about this bet, so I kept using NextJS once again until I found that I wasn't happy with I was doing so I ended trying Blitz and then I felt relieved. I understood docs, I liked how it was using the tools I added to NextJS like Prisma and thanks to your authentication option I was writing code happier than ever. I'd like that Blitz would come out of beta version as IMHO it would help Blitz to get more users, but I understand that it's not fine to struggle with NextJS as you state later. NextJS is great but Blitz helped me to use it in a better way and I will continue focusing on Blitz.
I'd like to be a better coder so I could help you more with Blitz so I can only give you this advice, if this pivot can reboot your motivation and gain more time for providing new features, please do it. You've shared your time with us and I think it's a thoughtful decision. I know that the community will do their best to migrate current code to the new framework. |
Beta Was this translation helpful? Give feedback.
-
|
Really nice your comment, you love your work |
Beta Was this translation helpful? Give feedback.
-
|
I also met blitz in a similar situation, I looked at it and I thought, it's based on Next JS I will continue on Next JS… Finally I decided to give it a try and the amazing documentation for blitz authenticação and useMutation useQuery! It was perfect, now my biggest question is, when will all this happen? Do you already have something ready? I'm going to give the new blitz a chance as I didn't the first time I saw it, because if it stays similar it's going to be a hell of a project. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the detailed proposal. I remain glad that I chose Blitz, for the inclusive culture as well as the technology. I once maintained a Rails app that was built during the Rails beta, by a Rails dev. The process of upgrading in those circumstances was painful indeed! I am keen to help find a way to smooth out the path here. Thanks again for all you've done. |
Beta Was this translation helpful? Give feedback.
-
|
Great writeup. Love the incremental adoption path for Next.js users, and the ability to bring this experience to most people. I've always felt the |
Beta Was this translation helpful? Give feedback.
-
|
starting w basic data: I do think it would be interesting if we could find out why the spike in March has come and gone to me it looks like blitz has gone from 2k/week to 5k/week and next has gone from .8M/week to 2.2M/week. Not a major proportional difference imo. (although we would really want to compare to Next in 2017, not this year) I can see if you were expecting exponential growth there is a problem but I'm not convinced we have hit the exponential increase part of the S curve yet. Scaffolding seems to be a core value prop imo and we still have plenty of room to go. Kudos on recently merging this feature for example: beyond the data, to the main discussion: Let me argue in favor of 'playing nice with Next' Before I do that, let me be clear that 'playing nice with' doesn't need to mean maintaining a fork. However, we all know that Next released some really cool features this year and as a developer I want to be able to use those. As long as Blitz enhances Next, I love Blitz, but as soon as Blitz becomes hard to use with Next, I expect to lose out on the current use case (true, maybe it will find some other use cases) I see a tradeoff between "wide scope" and "deep scope" and I would personally prefer deep scope. I don't want a CLI tool that can scaffold a single basic form over many languages and frameworks. I want a CLI tool that can generate complex code within React world. Consider the I also worry that becoming framework-agnostic is a step away from the value prop which is to have strong opinions. Next is the go-to SSG+SSR in React world and Blitz enhances Next. If Blitz stops enhancing Next, Next will remain the go-to and Blitz will be what? A competitor? An incentive to use Svelte or Remix? That seems to be a worse situation. In conclusion, i think it's basically a mistake to change the vision for Blitz. The new vision seems to align with a new and different project. We could simply have two different projects. The cost would be split attention, but the benefit would be A/B testing the growth curve. I'd recommend A/B testing personally. |
Beta Was this translation helpful? Give feedback.
-
|
thank you! On the blitz downloads, at the current scale, it's as good as flat. I.e. with the number of new projects being created in general, if we aren't growing faster than this, we are decaying. Also, on average 400 new blitz projects are being generated every day. At that rate, I would expect downloads over time to be growing a lot more.
Blitz will absolutely continue to enhance Next.js. Nextjs will be our primary target. But at the same time, we'll be architecting our new packages to be framework agnostic and have an adapter for Next. At this time I'm not committing to providing the full Blitz experience for other frameworks, but the possibility is now there. Even if we don't put much effort now into other frameworks, it leaves the door open for us to do so in the future if everyone migrates to Remix for example. Or some new thing coming down the pike.
The vision remains the same. The DX remains the same. The implementation changes. |
Beta Was this translation helpful? Give feedback.
-
Except that Remix doesn't offer anything significantly new. I've watched 4 videos for Remix and I'm still scratching my head on what it offers over BlitzJS. If anything, it's being touted as an improvement over React CRA. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarification! I'm all for a pivot if we can maintain a focus on deep React-world value compatible with Next. So you are moving me in a positive direction 😄 but I want to do my best to represent an ironman argument for a rationally cautionary approach. If you visit https://blitzjs.com/ today you see in large letters I think it's a bit more than an implementation change to remove the term Now we see: The risk I want to guard against is that support for other frameworks might become a shiny object that distracts from what many perceive as a core value today. I really can't stress this enough. Blitz will face tradeoffs between depth and breadth of framework support because different frameworks make different assumptions and hold different patterns which are exclusive to one another. Blitz will be forced to:
Because I have an interest in deep value within React world (which seems like the original vision to me) I would suggest option 2: Hope this was constructive! I can see that maintaining a Next fork is problematic and that a library toolkit approach is more flexible and facilitates other use cases. Nuxt mirrors Next, so probably Nuxt users could consume the toolkit with minimal depth sacrifice, but the next/nuxt paradigm is greatly different compared to the Angular Universal paradigm (which already has a cli tool and strong opinions anyway) and it's also different from the SveltKit paradigm, etc. These are things you already know I'm just calling them out to hopefully convince you to emphasize Next enhancement over true framework agnosticism. |
Beta Was this translation helpful? Give feedback.
-
|
100% agree with "depth scope" > "wide scope" as well as benefitting from new NextJS features. BlitzJS being a frameworl allows Platforms like Vercel, Netlify, AWS and others to provide "zero-config" deployments, which improves DX a lot. Being a toolkit will make life harder on the deployment site. Which is a huge DX selling point of NextJS+(you name it) IMO. Blitz could provide its own platform, while having copy-paste configs for other providers. "depth scope" vs "wide scope" |
Beta Was this translation helpful? Give feedback.
-
|
Full support on the pivot ❤️🚀 I'm definitely a fringe user who avoided building anything real with blitz because a pivot like this hadn't happened yet. Moving to an add-on for fresh next projects (and perhaps in the future remix etc) would convince me this project is future-proof enough to build stable apps upon. I'd definitely love to see the next ecosystem fully embraced before an over-extension into other ecosystems too :) |
Beta Was this translation helpful? Give feedback.
-
Great way to put it :) |
Beta Was this translation helpful? Give feedback.
-
|
For whatever reason, if we give up a project before it reaches version 1.0, I think it's a pity! In my opinion, we should at least reach |
Beta Was this translation helpful? Give feedback.
-
|
My point is there's no objectivity "between" how different projects by different people give it a 1.0 moniker. Use OSS, gauge the community, and make up your own mind. |
Beta Was this translation helpful? Give feedback.
-
|
On the blitz website, it says
|
Beta Was this translation helpful? Give feedback.
-
|
If you're using 0.x software, the library maintainers tell you, that you need to expect breaking API changes. Of course you can still use it in production, but updates (including security updates) might break your application. Using 1.2.3 means that updating to 1.2.4 includes no API changes, only bug fixes or security fixes. Updating to 1.3.0 introduces new APIs while not breaking existing ones. Only updating to 2.0 might break backwards compatibility. That's security for developing and maintaining applications, where you do not want to risk breaking your system for minor updates. BlitzJS has not reached it. Will not reach it. I expected it to be right around the corner. Now we will have to wait at least several more months (or years?) until the toolkit might become stable. |
Beta Was this translation helpful? Give feedback.
-
|
Put the 1.0 tag on the current state makes it possible to name the new pivot blitz then BlitzJS 2.0 (like the new Angular version 2) |
Beta Was this translation helpful? Give feedback.
-
|
Increase in major version also means breaking change. In that regard, staying at 0.x.x would at least provide that semantic safety, as most package json files would stay at |
Beta Was this translation helpful? Give feedback.
-
|
We have considered blitz for an application we are developing and didn't choose it. That's because the
To me, blitz is a full-stack framework. And frameworks tend to make decisions for you. NextJS as a web-framework decided to build on top of React. They provide their own solutions to analytics, images, APIs, etc. That's many decisions that teams don't need to make any more. I liked how Blitz as a full-stack framework went further, being based on NextJS. Choosing Prisma for Database connections, providing solutions to sessions and auth. A blitz-toolkit will provide some flexibility while loosing all the advantages of a framework. Also, for the maintainers, supporting all web-frameworks or component libraries will most likely be more complicated to support. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe being loosely coupled to nextjs is a good option? |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice if Blitz were like Nestjs; having fullstack, microservice and serveless capabilities. But without the complication that is Nestjs. |
Beta Was this translation helpful? Give feedback.
-
|
I totally understand where the idea comes from and I respect your decision if this happens. While I am not a fan of this switch. Our stack is stable (React + Next) and we just launched a product using Blitz. If you increase the codebase to support other frameworks the quality of support for our stack will collapse and the chance is high we have to rewrite the codebase using a more focused framework which I d like to avoid. Would it not be better and safer to start another project if you feel Blitz is not fun to make anymore? |
Beta Was this translation helpful? Give feedback.
-
|
Correction: "Reason is flat growth curve". I hope WebSockets will bring the expected growth curve :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you everyone very much for your sharing your heart on this. I'm much more aligned with you than it might first appear! I can emphatically say that Next.js is our primary and most important target. We love the DX we currently have, and it's very important for us to maintain that with this transition.
I guess it may depend on what "first party" means, but it's absolutely our plan to have nextjs as first party support.
It seems there's some difference perceptions here of what and how much work is actually involved in supporting other frameworks. The whole idea with this pivot is to massively reduce our codebase and reduce coupling with nextjs. Reduce coupling with nextjs so that any small change over there doesn't cause tons of work for us, which is what has been the case so far. But at the same time keeping a very awesome Nextjs + Blitz DX. To accomplish that, we are extracting out our current code like zero-api and auth into standalone packages that have zero framework integration. Then make a tiny adapter for nextjs so you get that sweet, sweet integration without lots of manual work or boilerplate. This does the following:
Therefore this is the right choice even if we never want to support other frameworks. A side effect is that now people can use our standalone packages with any framework with some manual work and some boilerplate. If usage is growing then it makes sense for either the community or maintainers to make a framework adapter to improve the DX.
I totally feel your worry here. We should definitely spend the most maintenance effort on what is being used the most (currently nextjs by far!). I guess it will take some time to see what it's actually like, but I highly expect framework specific issues to be a minority of issues. This metric can help guide us on whether to spend any energy on other frameworks in the future. I think a point worth emphasizing is that the current Blitz core value (zero-api, authentication, authorization, conventions) has very little to do with nextjs. It's normal JS and web requests which is the same across frameworks. In summary, I'm keeping on open mind about whether we have first class support for other frameworks or not and if so, how much. I'm not committed to supporting Remix. The only thing I'm currently committed to is the Nextjs integration and having our core components decoupled from any framework. How do y'all feel after hearing this? |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great. First class support for Next.js only to start, focus. While having an open architecture to allow for relatively painless support of other frameworks, and those second class support can very much come from community contributions. |
Beta Was this translation helpful? Give feedback.
-
|
I believe having the zero api and other tightly-knit/integrated modules extracted would also ease contribution 👍 |
Beta Was this translation helpful? Give feedback.
-
💯 💯 This is the way to go. Thank you Brandon! 💯 💯 Imagine you use multiple frameworks for different use cases, e.g. mostly Next and sometimes Remix and you could bring your Blitz-toolset to the job whatever you work with. That'd be a use case for us at least. The real implication of this pivot though is, that now millions of Next (!) users are just a
THIS, too! I was once thinking about making some little change to the codebase, then was like: ...uh oh... it's within the Next.js fork... can't touch this! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
There's a lot of truth in these observations @paulm17, @PixelsCommander, especially in comparing this to Prisma and regarding project scope vs available (very limited) resources. I consider the new Blitz.js (beware, elevator pitch) "the Prisma for frontend". There's a central difference, though. Prisma needs to wrap and map multiple fundamentally different databases to a single unified interface, to deliver its value. Blitz, as any other JS-library, does not have to do that. The adaption for frameworks like Next.js or Remix is not comparable to that. That's because web frameworks like Next etc. usually tend to work with other JS-libraries, or at least, with other React libraries. As long as the common denominator is React, I don't consider the effort in the same league as what Prisma has to do. I think the effort is in fact far less than maintaining that Next.js fork. That said - I share your view, that project scope should be super-narrow, sharp and focussed - at least in the beginning.
|
Beta Was this translation helpful? Give feedback.
-
|
If user numbers are one of the biggest concerns of switching to something that promises to be more flexible, then I think a more feature complete Blitz focused on Next/React would help a lot more to have people adopt Blitz, than freedom of choice. I am already choosing a full-stack framework! I expect to make trade-offs to have less to think about. So I don't mind having next and react as solid base to work with. BUT! If there is only one choice, I expect it to be well integrated and somewhat feature complete. Like with ORMs attempting to focus on all databases, I saw a similar problem and trend with other software. Ionic tried to please everyone at the same time also. Ionic, which first focused on Angular, then went on to invent entire new toolchains like stencil to build their components for vue and react also, had only a slight increase in userbase. The 2020 Survey showed, that of the original userbase, roughly 85% stayed with the only choice Ionic was able to offer previously: Angular. I do favor the other feature @flybayer proposes, and if switching back to original next provides that, I would very much prefer that, but I would not like to give up the comfort and DX I am having right now with automatic resolution of resolvers and grouping my features into domains with a pages folder sitting inside a |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Ionic's example isn't a useful parallel, as it has its own "why Ionic" beyond "adopting React didn't move much of the needle". I know as I was evaluating Ionic and in the end, why? It's still just a mobile Web app wrapper, I might as well go full native with React Native. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you everyone! I gave a long response in the above thread: #3075 (reply in thread)
I assure you that my #1 priority is "developer needs". A key reason for the pivot is that we were failing on our promises to meet developer needs. I've heard from a lot of devs that stopped using Blitz this year because of snail's pace on feature development.
The only thing that isn't currently possible with Nextjs is having multiple pages folders. But this is something I can put together a nextjs RFC for possibly they will be open to us adding this into nextjs core. |
Beta Was this translation helpful? Give feedback.
-
That's great. IMHO, it's more important to be able to colocate components, queries, libs and mutations, than pages. There are some valid arguments for keeping pages in one folder, as it colocates the complete routing definitions of a website.
That's why I'm a bit skeptical that this one will make it. 😅 |
Beta Was this translation helpful? Give feedback.
-
Update Jan 11, 2022Thank you everyone for all your input!! We are moving forward with the toolkit pivot, focusing primarily on nextjs support and a fully seamless migration from current blitz. I can't promise a timeline, but we're eyeing February. And after a very short beta/preview period, we'll release it as 1.0. We'll post general updates here. And we'll post zero API updates to the zero API RFC as we have them. And if there's any other things with more than small changes we'll post RFCs for them too. If/when we get to place where it's easy for y'all to contribute to cleanly scoped issues, we'll let you know. I hope your January is going well, and you're staying safe! |
Beta Was this translation helpful? Give feedback.
-
|
Heya @flybayer - I'm back online now - how do you want to proceed with the potential of tRPC + Blitz.js partnering up? I'm sure you've given it some thought over the last few weeks. I'm still keen to see it. I think there'll be a way of doing most or all of the things you want without compromising the existing Blitz users. |
Beta Was this translation helpful? Give feedback.
-
|
@KATT didn't get much time to focus on the zero-api part 😅 . We're currently working on the plugin system. Concerning tRPC collaboration, this is still our current thinking. |
Beta Was this translation helpful? Give feedback.
-
|
So how is it going? |
Beta Was this translation helpful? Give feedback.
-
|
As a Next.js Dev I am thrilled to adopt blitz into my current project and maybe further projects as well. And I think @flybayer has true balls to 1. try to compete with next, but 2. also does not fear to officially stand up and make a pivot in to the direction were most of devs can benefit from. You are my hero bro :) |
Beta Was this translation helpful? Give feedback.
-
|
Actually he's technically not competing with Vercel. I think I'm right in saying that they have no interest in the backend. They've as much signalled this. What he is doing. Which is something that is desperately needed, is to provide a "laravel" for the node ecosystem. Take a look at this example: https://news.ycombinator.com/item?id=29806385
I don't want to get into the contents of the link, this comment says it all 😅 . If @flybayer can develop a true library independent backend framework, which can then have interoperability with whatever FE framework is in the ecosystem. Then he should get a significant following. I'm sure there will be many people wanting to try out the toolkit in their preferred FE language. I'm also very happy with his last two statements. I am definitely rooting for him and I hope by the end of this year, there is something significant from all his efforts. |
Beta Was this translation helpful? Give feedback.
-
|
Just wanna say once I can use Blitz with Vue I will jump ship from Laravel immediately. Thanks for all your work. |
Beta Was this translation helpful? Give feedback.
-
|
Super excited for this pivot, are there any rough estimates as to when we can expect the newest pivoted version of blitz 🙃? |
Beta Was this translation helpful? Give feedback.
-
|
I think @flybayer said they were aiming for a Feb release. But I'd rather they hit the target, even if the release is somewhat delayed. Still super excited as well! |
Beta Was this translation helpful? Give feedback.
-
|
Aiming for March now :) Work is in progress on the |
Beta Was this translation helpful? Give feedback.
-
|
Amazing! Appreciate all the hard work being done by you @flybayer and the rest of the Blitz JS community! Can't wait for launch. |
Beta Was this translation helpful? Give feedback.
-
|
@flybayer @siddharthsharma94 So is the pivot completed now? Just want to confirm as I am new to Blitz. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
current status you can see here: |
Beta Was this translation helpful? Give feedback.
-
|
For the proposed new toolkit, is the implementation of the "Zero-API Data Layer" feature 'almost' complete? Could you pl. tell me the names of the folders / files where this code is lying. I am following Blitz closely since the last one year. When you decided to import the Next code in Blitz and started modifying it, I was like Blitz may fail because of this. Well, you have finally decided to make Blitz framework-agnostic, I appreciate it. You are looking forward to make Blitz a feature-rich full-stack framework. A suggestion in this regard. Keep it as flexible as possible and try to use the proven, stable Node modules. For example pino and winston are very popular loggers. If possible, create a logger plugin in Blitz and the developers should be able to plug the existing logging module of their choice. Similarly for Message Queues, let them use bull or kafka. |
Beta Was this translation helpful? Give feedback.
-
|
Greetings, I was just curious as to the status of the Blitzjs pivot. Mostly, I was just curious as to when we could get our hands on the first build post-pivot 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Not just responding to you cryptic but wanted to re-iterate what was said in a few other places as most people will end up here.
I thought the estimate was around March but it may be further in the future. Update: |
Beta Was this translation helpful? Give feedback.
-
|
How much work needs to be done to use |
Beta Was this translation helpful? Give feedback.
-
|
Just recently I've started to use Blitz and I've to admit, that the DX is top. The actual comparison with nextjs is difficult. Next has a solid funding, I am seeing vercel ads on twitter every day. Next.js is there since end 2016 and got support from some influential people like Arunoda Susiripala who was very influential in the Meteor.js community. So, I would say you need to start a company, which will provide hosting, db, file uploads, image-compression/rendering, real-time features, GDPR conform analytics etc. and provide a full-packaged dev solution to users to get the right funding. However, you definitely have to sell services and heavily advertise the product, to grow the user base. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I remember the original post talking about allowing sveltekit. The only thing stopping me from this is having to use react. Are you guys going to work with sveltekit in the timeline? |
Beta Was this translation helpful? Give feedback.
-
|
Someone try to adapt Blitz for SvelteKit: |
Beta Was this translation helpful? Give feedback.
-
|
Honestly didn't want this to happen all together but after considering the entire framework landscape right now , i feel this is more than the right way to go. Make Blitz more of a language tools than a framework tool |
Beta Was this translation helpful? Give feedback.
and others
Update Jan 11, 2022
Thank you everyone for all your input!!
We are moving forward with the toolkit pivot, focusing primarily on nextjs support and a fully seamless migration from current blitz.
I can't promise a timeline, but we're eyeing February. And after a very short beta/preview period, we'll release it as 1.0.
We'll post general updates here. And we'll post zero API updates to the zero API RFC as we have them. And if there's any other things with more than small changes we'll post RFCs for them too.
If/when we get to place where it's easy for y'all to contribute to cleanly scoped issues, we'll let you know.
I hope your January is going well, and you're staying safe!