Other tools are AMAZING for spinning up actual fullstack apps and use cases that require persistent storage. But actual product teams aren’t asking for that.
Also, our customers tell us that anecdotally it feels like we error less compared to other tools because we are focused entirely on frontend (there’s less room for error). Of course, we still error a lot - not easy when natural language is your input set!! - but it helps to stay focused and theres less dependencies on a backend & database.
p.s. one of my personal favorite parts of Magic Patterns is that you can very easily revert to a previous version, which is possible because no backend or database!
I love the idea. I just tried it for the office software suite I'm building and although I wouldn't copy-and-paste the design it suggested, it gave me a few ideas to iterate on, and that's already useful. I'll explore it further when it's time for more design thinking (I'm pretty set on my current design for now)
Interestingly, part of the value of the project I'm working on comes from bundling an AI assistant so that you can get documents (spreadsheets, presentations, documents) from natural language, so there's some overlap--the obvious difference being I'm trying to build complex documents instead of complex UI
Awesome to hear — our goal is to get to a point where you can copy/paste the design, but we totally recognize that it doesn't always get you to a full high fidelity mock up with the current limitations. So the main use case we've seen a lot of success with is ideating and validating different branches, quickly.
Oh that sounds very neat — definitely similar in nature! Documents and UI are both complex and can require a lot of iterations to get right
FWIW I think it could get a pretty high fidelity mockup if I had spent more time with it! It was remarkably good for a single one-shot prompt which probably had 15 words or less. I'll definitely come back for more when the time is right.
Definitely — we've seen some pretty crazy high fidelity mock ups from our customers who spend hours and hours prompting away, and they genuinely blow my mind. it's honestly why we spend so much time working on the application layer (e.g. making it easier to feed context into your prompt, referencing other designs, etc) since we know that the LLM is capable of these things, it just takes much more time than most people are willing to put in.
would love to hear what you think when you give it another try!
to add on to Alex's answer above, we also differ in that we have a lot of features focused around brainstorming / exploring ideas, versus just spinning up a fullstack app. For example, we have a "Commands" feature that lets you get four variations (that are guaranteed to be different!) of a prompt.
We also have a Chrome extension that lets you import designs from your existing product to ideate on top of existing content.
i hate working with DBs via command line, so this looks really cool. curious if your product resonates with a specific segment of developers, e.g. frontend vs backend? Hoping this can entirely replace me needing to do anything DB related in the comamnd line...
Yes! I too am not a huge command line fan (unless it's git for some reason), my background is actually in design so it was really painful trying to access DBs at first and the only options were the CLI or tools that look like they were built 20 years ago.
That was actually the catalyst for creating Outerbase! We have all types of people using us today, honestly we resonate really well with anyone who needs access to a DB. Frontend folks love us because we're a more modern way to do it and we line up really well with other modern frontend stacks, backend folks like us because we are really focused and make it straightforward to manage your data, and non-technical teams love us because they can actually get the data they need without needing to be a DBA.
To be honest, as someone who like semantic HTML, it's a pain to search for an appropriate tag and then try to figure out how to undo all its quirks and re-style it.
Semantic HTML was always a wrong half-solution to the problem. A website is always going to need custom semantics, the random grab-bag of whatever ideas people had back in 1993 is not a good set to base anything on.
The basic idea is if you have n ways your page can display, with the old PHP/CGI whole page refresh model you needed to write n endpoints, but every interaction required a slow and disruptive whole page refresh
With pre-react single page apps, if you had O(n) ways your webpage could display, you needed to write code to account for n^2 ways that each of those n states could transition into another one of those n states
With react, you write code to render n pages, and get the fine grained interactivity for free with good (enough) performance. It basically removed a tradeoff/dilemma that had been facing web developers since time immemorial, so no surprise it was a big hit
hey! other co-founder here — yeah, it does go through our backend systems for processing. We also store it in our db so people can iterate on it further in our web app. At the moment, no designs created via our extension are actually featured in our public catalog, but we do also support a private option for those folks who need private designs!
This is neat. I worked on something similar to college where we built an app to track how long the line was at a popular cafe. We set up a camera + raspberry pi in the cafe and tried to the number of people. There was a lot of noise from overlapping people, random people walking in and out of line, etc. Cool seeing all the techniques and approaches you tried!
the easiest 3 is an equilateral triangle split in half with any shape containing it - for 4 split the container perpendicular to the split in the triangle.
Also, our customers tell us that anecdotally it feels like we error less compared to other tools because we are focused entirely on frontend (there’s less room for error). Of course, we still error a lot - not easy when natural language is your input set!! - but it helps to stay focused and theres less dependencies on a backend & database.
p.s. one of my personal favorite parts of Magic Patterns is that you can very easily revert to a previous version, which is possible because no backend or database!