15 ms·

This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to prevent

This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. There are also lots and lots of products that take a "npm+glue" approach - they ship an initial version that leverages everything possible, and then run aground trying to make it to version 2, because the architecture is so reliant on the dependencies that it can neither be maintained nor support any additional features. This is a little bit different from the "Electron problem" in that it identifies a showstopper limitation to using developer-side easings, rather than a long-term paper cut issue.

panic 10y ago
This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. Sure, but everyone's always planning for the future when they choose databases, backend architecture, etc. Why not plan for the future in user experience, too?
- photojosh 10y ago
  Keeping I'm mind the things I've developed are niche and not large; a dozen users at one time is about as far as I've got.... With databases, I use SQLite for quick prototyping and single user apps, and Postgres for the multi-user ones. If I needed to scale, I'd optimise my queries better and consult an expert. With backend architecture, I'm most experienced with Python, Django & Twisted. I know these are used in web-scale apps, so if I needed to scale, I'd once again optimise best I could and consult an expert. Now, UI is a different kind of scaling problem, because ideally it's going to look and interact the same for 10 users as it does for a million. You're scaling based on the features you add as opposed to the number of users. How do you scale that? I'd say it's just as is happening now; you rewrite the UI as you scale, because if your revenue grows with users, you can afford to. On mobile devices: web page -> mobile app with mainly HTML views -> full native UI. On desktop: background server + webpage (think Plex) -> Electron/web-tech-based app -> full native app. The problem ends up being when your revenue is independent from number of users and you don't have the resources to do the rewrites. Or as is likely the case with apps such as Atom; a big part of your proposition is the availability of plugins from third-parties.

panic 10y ago

This equation starts with 0 users and grows pretty slowly at first. It only flips once you have a critical mass of users, and by then it's "too late" to preventatively fix the architecture to bias to performance. Sure, but everyone's always planning for the future when they choose databases, backend architecture, etc. Why not plan for the future in user experience, too?

photojosh 10y ago
Keeping I'm mind the things I've developed are niche and not large; a dozen users at one time is about as far as I've got.... With databases, I use SQLite for quick prototyping and single user apps, and Postgres for the multi-user ones. If I needed to scale, I'd optimise my queries better and consult an expert. With backend architecture, I'm most experienced with Python, Django & Twisted. I know these are used in web-scale apps, so if I needed to scale, I'd once again optimise best I could and consult an expert. Now, UI is a different kind of scaling problem, because ideally it's going to look and interact the same for 10 users as it does for a million. You're scaling based on the features you add as opposed to the number of users. How do you scale that? I'd say it's just as is happening now; you rewrite the UI as you scale, because if your revenue grows with users, you can afford to. On mobile devices: web page -> mobile app with mainly HTML views -> full native UI. On desktop: background server + webpage (think Plex) -> Electron/web-tech-based app -> full native app. The problem ends up being when your revenue is independent from number of users and you don't have the resources to do the rewrites. Or as is likely the case with apps such as Atom; a big part of your proposition is the availability of plugins from third-parties.