I suspect the frequency of people asking this type of query is low enough that mainstream apps will likely never implement such a feature.
However, it would be interesting to see if you can solve this kind of problem using GPT or replit. I expect AI to cover all such longtail use cases by quickly whipping up not-so-perfect but gets-the-job-done apps/code.
Unrelated to the OP product but I’m curious how people are solving this issue on smaller scale with nextjs + prisma/drizzle. Do you just run the builtin migrate script with npm run?
We use a CI job that runs drizzle migrate whenever the schema files change. Drizzle doesn’t have rollbacks though. Replacing this process with pgroll as a sort of drop-in replacement would be nice. Then orchestrate everything with a couple of CI jobs, and done!
Auto-complete on steroids sounds like the correct assessment.
Aider & Cursor is worth the try if you're interested in trying out multi-file edits. I think both are interesting (ergonomics-wise) but the current SOTA models do not perform well.
For single file edits or chat, I would recommend Cody (generous free tier) or some self-hosted alternative.
If you're looking for a technical job, the easier path would be to find a PM/Designer job at one of your target companies and try switching to a dev role within the company. When you apply as a junior developer, your previous work experience will not be considered relevant. You'll be competing with other junior developers (who also likely don't have any relevant work experience) and it's much harder to differentiate yourself. Whereas if you want to switch roles inside a company, people who are familiar with your skills are likely to take a bet on you (if you have a good track record).
On the other hand, the masters program will introduce you to a new network of people, and working towards a goal with a cohort is much more motivating than learning by yourself.
I agree with your suggestion with one caveat: having a Master's degree when switching to a dev role would be very beneficial. Both in terms of how it looks on paper and in terms of competency.
The hard part is not going open-source today but remaining open-source as your product evolves. When using a split model like this, inevitably the open-source version serves SMBs and the paid version serves Enterprises. Given enough time, you end up having two different versions of the product for two different customer segments and logically axe the version that doesn't make you money anymore.
It's likely not even going to be a conscious or intentional choice. At some point your enterprise customers are going to have enough bugs and feature requests to keep you busy full time, and your open source project might languish unless you make a conscious effort to dedicate a percentage of your time on it.
Ironically as some companies have already started noticing, when you stop being able to market your product as open source the start of the funnel will start to dry up. The start of the funnel is often not monitored, and the sales might even continue going up as your successful open source users go to enterprise. By the time you realise the funnel has dried up it might already be too late to turn back as competitors have filled the void you left.
In my opinion, this just means you've done a poor job on the architecture side of things. If you need a paid version that has extra functionality then your free version needs to be extendable.
Your free version should in theory just be a freemium version of your product. And your freemium version of your product should lead to paying customers and be a major way of generating leads and customers. If it's not doing that then it should be a case of do you need to stop adding so many features to the free version or is it that a free version just isn't used by enough people to even matter?
If no one is using it, then really stop building it you're just wasting your time just so you can virtue signal that it's open-source. Really, the only people who will be mad will be the ones not helping you out.
When your enterprise product is a superset of your open source product, you need a trigger that leads to buying. If that trigger is a feature, then it is only effective as a trigger if it is broadly useful to the product. In which case, you either withhold it from open source or cripple (or rate limit it) in open source. Your sales team - told to meet quarterly revenue targets and held accountable to that - will lobby for strict limits on these features.
My first hand experience is that there are two likely outcomes: (1) You limit the utility of the open version to create a buying trigger and your open source users dwindle away as the open product doesn't meet their needs. Or, (2) your community has sufficient momentum to build the feature itself and your sales team starts losing deals to your open source offering.
This model also creates harmful intra-organization conflict between those who argue for short-term revenue (probably their continued employment depends on that) vs. those who argue for the largest open source user base. It also creates conflict with your users as you intentionally offer a worse product to your largest user group (open source users).
I didn't know about the @container queries, they look interesting.
Having said that, I'm not a huge fan of pushing more state logic to CSS. I understand the benefits (from the github page) but pushing more text into the style string without thinking about tooling (how to debug etc) is dangerous.
This is what most people want + some utility functions & good default variables (for colors etc).
If you're doing relatively straightforward things, tailwind is super easy to work with and that's why a lot of people prefer it today. Having it inline makes it easy to digest (both for humans and LLMs) until things get complicated.
I see this similar to using javascript in your project. When you start fresh on a new project, typescript can be seen as a bottleneck, slowing you down. As project evolves your needs also evolve and other solutions might be a better choice.
This reminds me how google conveniently made the switch to manifest v3 when there were legitimate use cases like adblockers. Sure, technically speaking v3 is more secure and that may be better for users but your comment just made me think the opposite is in motion here.
Nothing wrong with manifest v3. It's just that ad blocking is so important that it should be an exception to the whole thing. Ad blockers should be literally built into the browsers so that they have full access, only conflicts of interest stops this.
The game and the story are good but are nowhere near as polished as some AAA titles (eg it has bad English dub). The DEI contraversies around it caused streamers to talk about the game often and served as advertisement (since the narrative was DEI vs Gamers).
However, it would be interesting to see if you can solve this kind of problem using GPT or replit. I expect AI to cover all such longtail use cases by quickly whipping up not-so-perfect but gets-the-job-done apps/code.