We're investigating this now. Early experiments are very promising.
HN user
palmdeezy
[ my public key: https://keybase.io/jaredpalmer; my proof: https://keybase.io/jaredpalmer/sigs/OdvbGAkU9fMFmOQptxHQNrvYrmCIZpusW4TmMO7ua5M ]
v0 is really for everyone. We hope it makes everyone more productive and creative...reducing the cost of iteration and experimentation.
v0 saves loads of time by allowing you to quickly generate UIs with React via Shadcn UI (https://ui.shadcn.com) with simple text prompts. While full scale design tools are very useful, not every UI in your app needs that level of fidelity. Furthermore, a lot of UIs inside of apps and websites are already extremely programmatic (such as forms, tables, modals, etc.). The goal with v0 is to get you started (hence the name) faster....to give you something you can copy and paste and then modify yourself.
Jared Palmer, v0 creator/team lead here...
Happy to answer any questions!
Jared Palmer here... v0 Creator/Team Lead.
Tailwind is indeed required at the moment. However, we're working on supporting other popular design systems as well as custom ones.
Yes! This is something we'll be adding soon!
Hi everyone! Jared Palmer (https://x.com/jaredpalmer) here from the v0 team and Vercel. Happy to answer any questions. The team is very excited to finally share what we've been working on with the community. We know it's early, but as the name implies... it's v0.
Link: https://v0.dev | FAQ: https://v0.dev/faq
Hola! Y'all can play with LLama 2 for free and compare it side by side to over 20 other models on the Vercel AI SDK playground.
Side-by-side comparison of LLama 2, Claude 2, GPT-3.5-turbo and GPT: https://sdk.vercel.ai/s/EkDy2iN
Fixed Cohere and Replicate. Will add the other provider now! Appreciate the help!
Investigating now. Thanks for the feedback!
Correct. We are using various hosting providers.
As part of the project, I’ve been working with providers and hosts on updating their SDKs to work on Vercel Edge Functions (and streaming).
Thanks man! Good idea on token/s. Will add
Engineering Director of Frameworks at Vercel here…
It works automatically when you use the `app` directory in 13.2+. No additional steps are needed when you self-host/run on Node.js
Yes! Prune then zip the output folder.
Turborepo author here…
We do not invalidate the whole graph anymore for a lockfile change. We now have a sophisticated parser that can calculate if a change within the lockfile should actually alter the hash of a given target. In addition to higher cache hit rates, this is what powers our `turbo prune` command which allows teams to create slices of their monorepo for a target and its dependencies…useful for those building in Docker.
Prune docs: https://turbo.build/repo/docs/reference/command-line-referen...
Turborepo is much more scalable now than when we spoke pre-Vercel acquisition. It now powers the core web codebases at Netflix, Snap, Disney Streaming, Hearst, Plex and thousands of other high-performance teams. You can see a full list of users here: https://turbo.build/showcase
Would be happy to reconnect about Uber’s web monorepo sometime.
Turborepo author here...
* tasks on the root package (e.g. tsc -b that typechecks all packages)
We are working on this as we speak! The first step is to add the ability to restrict hashing `inputs`[1] to the Turborepo `pipeline`. After that we are going to be adding root task running in the next minor release.
However, as your monorepo grows, you will likely want to move away from running tasks like tsc from the root and instead run them on a per-package basis. The reason is that tools like Bazel, Buck, Turborepo, etc. can become more incremental (and thus faster) as your dependency/task graph becomes more granular (as long as you maintain or reduce the average affected blast radius of a given change). The other argument against root tasks is that they break hermeticity and encapsulation of the package abstraction. That being said, root tasks are very useful for fast migration to Turborepo and also for smaller repos. Futhermore, we're happy to tradeoff academic purity for productivity with features like this.
treat tasks such as lint:eslint, lint:pretter as a single task lint (or maybe `lint:*`)
You can run multiple tasks at the same time and Turborepo will efficiently schedule them at max concurrency.
turbo run eslint prettier --filter=@acme/...
However, it sounds like you like to see glob fan out of tasks. This is a really cool idea. I created a GitHub issue for it here [2] if you'd like to follow along.
Turborepo author/founder here....
Yes, it's possible. Databricks currently uses both Turborepo and Bazel together in their monorepo[1]
[1] https://twitter.com/elado/status/1504216742393876483?s=20&t=...
There are a huge number of mostly non-JS-specific problems that monorepo tooling eventually needs to solve: distributed build artifact and test result caching, distributed action execution, sandboxing, resource management and queuing, observability, and integration with other CI tools to name a few.
Turborepo author/founder here....
I agree. I built Turborepo because existing tools weren’t meeting our needs.
To solve these problems and still be flexible, many existing build tools end up with lots of configuration bloat. We’re trying to avoid that. We want to reimagine the developer experience of monorepo tooling and make it accessible for everyone.
This hit different. Exactly what I needed to read today
Hi, it's Jared (the OP)...
Well said. Perhaps my deeper point is that hooks and soon Concurrent Mode force devs to come to terms with the fact that they _don't_ understand React internals (hence my usage of black box) and that their mental models were wrong this whole time (although some might argue still pretty productive).
I also think Crank is SUPER interesting on so many levels. I built a few demos with it and am fairly impressed. However, practically speaking (and I'm putting my developer relations hat on), I think its generator API is just too intimidating to junior developers.
Number 2 would attract an enormous amount of developers. Can you consider doing an example of such a workflow with copilot and pipelines, including provisioning a LB and/or tweaking an existing one to get per-branch subdomains with https?
Yeah, I do wonder if there is room for innovation in the space around social features.
This looks great!
Styles.
I know Facebook has an internal CSS Module thing that is not open source ready. So this has been pushed off to user land. However, lack of an officially blessed style solution makes React components less reusable across projects compared to Vue. Thanks to vue-loader, the Vue community can focus on other things. I am NOT advocating for single file components like Vue, I am hoping that FB can just bless a solution so we can move forward as community.
What makes this all worse is that companies like Auth0 and Stormpath have flooded search results with self promoting blog posts masked as tutorials. This just makes it harder for developers to learn the basics without getting product shoved in their face.
This is a great overview. I find it interesting that there is still significant friction with setting up arguably one of FB's most useful ad tools....I also find it interesting that tracking pixels pretty much haven't changed since the late 90s.
Where can I read more about this?
Ahhhh so this will be super useful if I want to keep track of transaction events from a third party (like Shopify or Stripe). I could just keep table with `ID` `user_id` `time` `blob`.
Hey SQL newbie question: why use JSONB when you could split out tables into `user` and `user_meta`? isn't that how Wordpress works?
Instead of going for the quick take, spend your time writing one article a week that's higher quality with the intent of virality