I thought this statement from the article had more than a hint of truth to it: "Figma in Electron may destroy your battery, but that destruction will take twice as long, if not more, with an A-series chip inside!"
replies(2):
Also requires me have a working internet to be able to use it. Sketch or Affinity Designer don't have these problems. I hope they will fix that problem with Figma.
For a user, it may seem like 'why can't they just add sync', for a programmer, it's a little more complicated :)
And it's not just Figma's collaborative features. Figma made fundamentally better decisions about design tool feature set. Better vector editor. Better concept of "symbol" as a component. Much better approach to auto-layout. Much better approach to shared colors / text styles.
At every step, Figma is just a better designed design tool. And a large part of why it's taking the design world by storm is exactly that. Most design work is done alone, not collaboratively dragging elements on the screen. Figma is just a great tool. Sketch is trying to catch up, but they would need to modify a LOT of their past decisions to get to the spot Figma is at.
As a designer your work must be detached of workflow sentiments. Tools are tools. Nothing more. I can make a great UI with Inkscape any day I want.
Figma takes this a step further. Design components can be connected to JS components using Storybooks. Localization can be automatically applied to designs, and elements will automatically adjust because of a powerful, flexbox-like auto-layout.
Sure, you CAN make the same design using Inkscape. But Figma enables previously impossible workflows and makes the end result -- user experience with product -- better.
CADD is a 800lb angry gorilla sitting between you and your design.
Yes, it's a poor craftsperson who blames their tools. And, sometimes it's nice when the tool doesn't fight you every step of the journey.
I imagine the same is true for graphic design.
I think the hidden truth here is that "boring boxes" solve most problems pretty damn well.
Unless your product is literally art/design, then you don't need anything custom, and boring boxes are probably the correct choice.
There is some wiggle room here - It's easier to attract customers with pretty designs, and you can make it easier to onboard a new user with some nice effects and design flourishes. But if you go overboard you differentiate yourself too much and make your product much harder to reason about and interact with.
As a user trying to get value out of a product I mostly don't care what it looks like. I do care a lot if slow animations or videos keep getting in my way. Nice the first time, fucking miserable on the hundred and first.
So if they…
- Add a full offline mode
- Ditch Electron for a more focused/lightweight webassembly+canvas implementation
- Open and document their file format to allay lockin concerns
…I'd be much more inclined to use it instead of Sketch.
Actually, that's exactly how Figma is built—their desktop app just wraps their web version while hooking into file system APIs provided by Electron/NodeJS. See https://www.figma.com/blog/webassembly-cut-figmas-load-time-....
A screwdriver and an electrict drill are both tools.
Although I find that the biggest performance impact is not Electron but that now you don’t have a local database and a lot of requests are going through the network before the caching mechanisms kick in.
In my opinion, it’s the correct move to make but incredibly hard. Now they have launched v10 they have at most and additionaa billing cycle (12 months) to start cranking out compelling features and polishing the product.
My concern with EN is that they bleed so many paying users that they end being unsustainable. Time will tell.
If you use the native webview, it’ll probably use less memory but be slower because it’s basically running Safari instead of Chrome. It’s probably the wrong tradeoff for Figma because the browser’s memory usage and JS heap memory is pretty negligible compared to the amount of memory the user’s document uses, especially large ones with a lot of images. There’s way more room for optimization there and that has nothing to do with Electron.
It’s fun to think about what the performance would be if it was 100% C++ given infinite resources but realistically it’d be way less productive and more bug prone than React. I’ve written UIs in C++ before，would not repeat. That time would be better spent optimizing actual bottlenecks, like rendering the design file (where the GPU is the bottlebeck).
We actually have a native (not WASM) with native webview build we use internally for debugging with XCode. No, performance isn’t better enough to warrant dealing with Safari issues and shipping that over the Electron + WASM build.
Funnily enough, I've read Emotional Design, It's been a long time (I think it was back in like 2006/2007) but my memory is that most of the focus of the book was on the design of physical objects. I don't really think website design has the same freedom. It doesn't invalidate all of his topics, but it certainly limits how they apply.
But there's a different angle here that I'd ask you to consider - Over the last 20 years, websites are eating up interactions that used to be conversations.
You might have walked to a bank and talked to a teller - Now you use their website.
You might have driven to home depot and asked a store associate a question - now you shop online.
You might have gone to blockbuster and rented a movie from the clerk - Now you browse netflix.
You might have gone to the post office to get some mail - Now that content is in an email instead.
Each of those interactions was just a conversation, literally just sounds coming out of a mouth, but they all achieved useful side effects. While you might have a pleasant chat every now and then, the goal was not reflective/emotional investment. The goal was the utility provided by the service.
I think approaching the design of a site with the goal of evoking an emotional or visceral reaction (ESPECIALLY from the literal appearance of the site) is actually turning the advice of the book on it's head - Put the user first!
If I'm interacting with your site to achieve a useful side effect, whether that's order an item, get the news, see my mail, deposit a check, watch a show, etc - Then my emotional reaction is heavily biased towards how well and how quickly I can achieve my goal. My emotions don't care a flying fuck whether your button is red/blue/green or if your gray is #d3d3d3 or #878787. And I certainly don't want to have to navigate a crazy custom design, just like I don't want to hit a detour while driving home - even if it happens to be scenic.
I do care, a whole lot, about consistently easy to use services, with a low barrier to entry. On the web, that mostly means boring boxes.
---
As a thought experiment, I'm sure you've been to the DMV before (I'm not actually, you might not be US based, but you probably have an equivalent).
Ever had that DMV trip that took 3 hours waiting in line before finally getting seen?
Not happy were you?
Ever had that DMV trip where it was basically empty and you got seen immediately?
I bet you felt thrilled. (probably an overstatement, but at least pleasantly surprised)
It's the same building, same carpets, floors, columns, windows, roof. The only change was how quickly and efficiently you accomplished the goal you had. But your emotional responses were miles apart.
Apply that to websites. I don't want to be looking at my bank's website - I do it because I need to move money or use their services. Make that the priority. Make it with boring, easy to use boxes, and I will love it.
Bury it in menus, or add 10 clicks because "that page looks a little cramped" and I will not be happy.