Hacker News Reader

Comment by andratwiro | Hacker News Reader

This is why I use Framer, they have a built-in export to React function that is really powerful for early startups (as the whole tool is built on React)

My team has been using our Framer export (with a few tweaks) as the actual final UI for our early product. Designing is as easy as in Figma, with the advantage that you have actual React components out of the box (working chart libraries, video components... any package you want to use). Whatever you design is responsive, can be connected via API to any database, and all of this is done collaboratively in the same document.

It has been a mind-blowing experience in terms of product shipping speed, and as a designer, it really makes you connect in a deeper way with the complexity of the final code.

View on HN

Framer is an awesome prototyping tool (I use it), but I would've wanted to know up-front that "export to React" comes with two huge caveats:

- There's nothing stopping you from using it in production, but it isn't designed for this. What you create does not even use real layout, does not use normal HTML elements, etc.: see https://www.framer.com/support/using-framer/creating-real-ap....

- Inevitably in any real-world project, various parts of the UI need to be changed/overridden from code. But you cannot iterate on the design once ejected, which is a significant limitation for any product that requires iteration.

For building prototypes, it works great, and it makes user-testing a "happy path" nice and breezy.

That said, would love to see/hear more about the projects you've shipped to production!

(Disclaimer: I work on https://www.plasmic.app.)

Agreed on both points, the export is definitely a hackish way of using Framer.

I'll be glad to share the project over DM, feel free to shoot me an email :)

Also, Plasmic looks really interesting, I'm looking forward to try it out.

I'm testing and absolutely loving Plasmic right now. Sent you a dm

Thanks for the kind words, that's great to hear!

We are in a very fortunate position financially (multiple years of runway), and I am YZ. :) We also have companies big and small relying on Plasmic in production. Lastly, you fully own the code that you generate, and can always eject with clean React.

All these design tool to code plugins never actually work for anything realistic.

If you're so keen on not writing code, you're better off using a page builder.

Design tools are specialized to do one thing really well. You should always use the right tool for the job.

You should check it out, because its actually the other way around. Framer is basically React you can tinker with and use actual React components, it just happens to have a great UI on top that makes designing with no code seamless, and whatever you design is React behind the scenes.

Page builders in my experience aren't efficient to design, this on the other hand makes designing easier (as I have access to interactive components, real client data, etc).

Yes, 150MB is crazy.

Isn’t that just a basic node_modules folder?

Umm pretty sure my node_modules is 1GB+ xD

Lmao

It's normally slightly larger on average. I get you're joking, but the joke doesn't even make sense. A full build of LLVM + Clang is 15-20Gb, and yet, weirdly, IOS apps are not all that size.

Sorry, not joking at all. Since it’s a React app I thought it might literally be a node_modules folder.

Ah apologies, I thought it was just a "hoho isn't node_modules big" comment. Yeah, its output: 150Mb seems hyperbole, but afaics it's not far off an order of magnitude larger than a normal React app.

Our designers are on Figma right now (they seem to switch every 12-18 months) but I kind of wish they’d switch to Framer, I’ve heard great things about the React export. We’ve been using Framer Motion, their animation library, for years and it is just phenomenal.

Framer motion is great, and its integration on the tool makes it deadly simple to use!

I think the export might not be so suited for bigger teams though. For reference, a simple 4-page navigation can lead to a +200mb file export, and its basically HTML within an iframe.

For the team as a whole, I think its more about having the designers speak the same language as devs on a shared interface. It empowers us as it makes exporting prototypes for user testing that can be easily hosted as if they were coded for real, and forces us to focus on interactivity & flows rather than the design per se.

Hey do you have some details on how do do this? I'm having some trouble figuring out how to do this from web app. Am I supposed to use the JSX details in the handoff pane along with the Framer react library? It seems like an incredibly useful feature and would really like to take a look.

You need to have a pro account to use the desktop version and make the export, and as we speak they are refactoring this version to include it in the web version.

On the – non Beta – Desktop version, it works as a single folder file (pretty sizeable, +150mb) that you can host anywhere, and renders the prototype within an iframe.

The team at Farfetch did a custom component to do something similar to what you mention (if I understood you well): https://youtu.be/LEMGL2NH0r8?t=2760

So you’re shipping a 150MB frontend to your users?

The actual load per page was around 1-5mb, so even when doing remote mobile testing in areas with low speed internet it wasn't an issue (although its definitely one of the main reasons to switch to a real react site when scaling the product)

I disagree. How did 1-5mb become an acceptable size to ship to your users? That's actually quite a lot. In a slow connection, this isn't even going to load anything except a blank screen for such a long time.

A desktop app quickly runs to 200mb. Why do we think it is so unreasonable for a full app on the web to take even 5% of that amount?

If you're talking a user downloading it with mobile data, it's gonna take a while before it can setup and show anything.

I think someone else said there are other optimizations that happen when you shop production code.

Because there's a LOT of people out there who have slow mobile data or poor signal strength. I think assuming that everyone everywhere has extremely fast internet is a bad assumption. Also there's an enormous amount of bloat in package sizes now, I don't think this really should be as bad as it currently is.

I agree 100%, in the use case I mentioned we were looking to either prove or disprove product hypothesis with real users fast so efficient code wasn't a priority, but rather to confirm wether what we were about to develop was valid.

You download a desktop app exactly once. You download a web app (almost) every time you navigate to the site.

This is, generally, not true for a web app with a caching service worker.

I don’t know what your caching settings are, but my users download the app exactly once, and then only again if I push any update (or their browser cache randomly decides to clear itself, don’t really have any control over that).

Aside from that, they use the app literally their entire workday, so spending 5 seconds loading the thing isn’t going to hurt anyone.

I think they’re talking about testing prototypes exported from the design app, not what they’d necessarily ship as a finished product?

Yeah testing is its intended usage, but on the initial phases of the product we did use it as the finished product clients were paying for.

It can be slightly hacked around to add user authentication & analytics, so if you are handling a small amount of users its a really efficient way to iterate fast.

The idea of these tools is to allow teams to test a wide array of hypothesis to then have data-backed flows that make sense to code efficiently. The size is an unfortunate trade-off for testing speed.

Of course the initial users will experience a slow product, but the idea is to discover faster what a useful product looks like without investing development resources.

I'm an efficiency freak, so I understand what you're saying.

But let us be realistic. I just loaded www.amazon.com - 17.8 MB transferred when it finally stopped. Arguably one of the most successful websites in the world.

A 5MB asset size for most sites is perfectly acceptable.

Yeah, I agree with you for the most part. And this argument comes up a lot. The difference is we're not Amazon yet. We don't have the same levels of user engagement, loyalty and whatever metrics that makes Amazon a success. To the end users, we're not as popular, one slow page load translates to a lost potential customer which when aggregated to even a few 100 potential customers could make or break a startup.

Reply on news.ycombinator.com