I am a huge fan of this stack. I love that Supabase is spending millions of VC money to popularise this stack, solving all issues, improving PostgreSQL and PostgREST, writing documentation, conference talks etc. kind of sucks the stack success requires Supabase to die (technology becoming commodity, which it already it, Supabase people did make everything open source, true to their promises).
Supabase has zero differentiation. They have a nice "PGAdmin" if you may, but no one will pay for entire database hosting because of an admin interface. When it comes to hosting DB AWS, Azure etc have massive advantage.
Supabase will simply popularise the stack, and then when time to actually host the database comes people will move from Supabase to AWS etc.
Also the best language for UI is not JS, but something like FTD if we continue to make the progress we are making. Hopefully FTD + SQL Is all you need to know soon. Checkout this design that we are working towards for making this a reality: https://fpm.dev/journal/#explanation-of-dynamic-documents-an...
> kind of sucks the stack success requires Supabase to die
this is a zero-sum view of the world. I'm sure that as the stack becomes popular, Supabase will too (and vice-versa).
> when time to actually host the database comes people will move from Supabase to AWS etc.
Databases are inherently sticky - it's the reason we started with the "Jamstack" crowd rather than enterprise use-cases. If you start on Supabase, and we handle all your scaling, there should be no reason to migrate to a different cloud.
> When it comes to hosting DB AWS, Azure etc have massive advantage.
given the (in)stability of cloud providers in 2021, I think we will see a trend toward multi-cloud in the the next few years. I'm not sure that they have such a large advantage (we use AWS so it's not like they can offer superior hardware).
IMO a disclaimer is lacking in your post. The product you recommend in the last paragraph seems to be made yourself and you're the founder of the company that makes it. Sure the "we" implies you're involved, but doesn't disclose the extent. I believe this is important when making a recommendation of the "best language" and hyping technology in general.
Point taken. But I am not hyping the specific technology here, I would be glad FTD ends up being the language, but I believe a FTD like like language is definitely needed. We need a programming language for human beings, that we can hope all humans can write. Unfortunately JS is not that language. You can do very little with just knowing JS, you have to learn a lot of other technologies.
MDX and Svelte in Markdown etc are definitely cool, but unfortunately they are not at all adequate for the job. You can not define a new component in MDX/MDSVEX, only use existing Svelte/React components in prose.
Further what about the arguments of those components, can they themselves contain markdown? How about markdown with React or Svelte component? Would you really with straight face say this is powerful:
<Penguin text="Some text, which itself contains <Another />" />
Just try nesting it or writing multiline text, its complete torture.
The example that shows up when you click "try" shows how to use markdown as slots inside components.
I'd suggest at least doing some research before trying to put down a potential "competitor"/alternative to your own tech. This whole exchange is a tad too unprofessional to me IMO.
The example shows when there is one body which contains markdown/Svelte. But I am talking about components that take more than one attributes. Say you want to model a person object. Person has many fields. You will have to write something like:
<person>
<name>markdown is okay here</name>
<bio>markdown is okay here</bio>
</person>
If you do this it goes in the order you wrote things down, the <person> can not decide to show bio before name for example.
If you write:
<person name="markdown difficult here" bio="markdown difficult here />
Now `person` has better control over things but it's not ergonomic to write. All the examples are "simplistic", when you have a complicated data modelling etc, this approach of leaving floating tags, eg `<name>` is not good modelling, its name of what? A person's name? A projects name? And can you get this data out of these files? You will have to write a full blown parser etc, any data in such file would be lost.
Also if you want to create a new component you have to jump to the Javascript world. And you have to learn CSS. Along with Markdown and the front matter (yml). Each with non trivial amount of learning curves.
FTD is being designed as a unified whole. All components of FTD are written in FTD. There is no boundary between "author" code and "components". A reasonable programmer can pick up FTD in an hr, check out the first video on https://ftd.dev. A non developer can pick it in a week, check out the other three videos.
Svelte etc are cool, but haven't you heard of huge number of backend developers who can't get into frontend? Current state of frontend is extremely complex. You can not tell me billions of people can learn Svelte thing when even backend developers are facing difficulties. To use mdsvex effectively you will have to write components. Which means the entire web pack, bundling etc etc. Do not pretend these are easy, anybody, even non programmers can do it.
FTD is being designed to be easy to teach. The audience of FTD is people at large, not developers (and yes they can learn some programming, Excel is used by 100s of millions). I do not believe you are saying Svelte is the super best and no such project as FTD must exist. I believe there is scope of improvement and we are working on it, help us improve.
Sorry if I haven't myself clear: I'm not questioning any technical merit of any tech. I'm just saying that I don't think this is a proper venue for advertising your product, as good as it is. This is off-topic. You should try a "Show HN" post. That's just a friendly recommendation, I'm not interested nor the target for your product.
FTD: https://ftd.dev/language/. A DSL for creating "programmable prose". Markdown with data declaration, event handling and soon arbitrary computation.
There are many rendering issues on their landing pages.
Things like unreadable elements with near 0 contrast between font and background and a dark mode with pieces of widgets with a white background does not fill me with confidence for a UI focused technology.
Hey, can you tell me what phone you are using and what exactly do you mean by "crashes my phone"?
Thanks for the design feedback. The theme is new. The language itself is new. The static generator is new. Sidebar issue on mobile, and contrast issue we are aware of and are working on. Markdown styling is not a trivial issue to fix as we do not allow authors or theme builders to access CSS directly, [1] is the design we have come up with.
Supabase has zero differentiation. They have a nice "PGAdmin" if you may, but no one will pay for entire database hosting because of an admin interface. When it comes to hosting DB AWS, Azure etc have massive advantage.
Supabase will simply popularise the stack, and then when time to actually host the database comes people will move from Supabase to AWS etc.
Also the best language for UI is not JS, but something like FTD if we continue to make the progress we are making. Hopefully FTD + SQL Is all you need to know soon. Checkout this design that we are working towards for making this a reality: https://fpm.dev/journal/#explanation-of-dynamic-documents-an...