3 ms·
"we'll build it in Electron" isn't a kludge or temporary decision though. It is an acknowledgement that there aren't enough devs on payroll to support a true-na
by roenxi 3y ago
"we'll build it in Electron" isn't a kludge or temporary decision though. It is an acknowledgement that there aren't enough devs on payroll to support a true-native app. The tradeoff is RAM for developer time and hiring efficiency. That is a pretty good trade; RAM is there to be used.
The technical issue here is that the protocol is closed, not that the client is fat. So someone in a RAM-constrained environment can't choose to make different trade offs. But the protocol being closed, while annoying as a user, is definitely a strategic choice.
- Analemma_ 3y agoPeople who constantly bellyache about Electron need to compare the all-up cost of one web developer-- of which there is a massive supply in the labor market-- versus one experienced native dev per OS, who are rare and expensive and getting more so all the time as the desktop withers as a development platform. That cost difference absolutely can be the difference between economic viability and unviability, but HN constantly seems to think companies only pick Electron because they're cackling with glee at the thought of wasting their customer's CPU cycles or whatever.
- progmetaldev 3y agoOn top of having different teams supporting each OS, because a company developing a project this large isn't going to have a small team where the developers know each OS (not quite full-stack in the web development stack, but just comparable to developers that know every OS they need to build for). There then needs to be communication between different development teams, as well as offering feature-parity across OS's, because your clients need to be able to communicate with each other across OS's since your product is a chat application for business. It's not normally acceptable to have features that are different between OS's when your product is meant for team chat.