4 ms·

> I'm not convinced that Electron today is any more popular than XUL was back then comex already named two highly popular ones (slack in particular can't be o

by M_- 10y ago

> I'm not convinced that Electron today is any more popular than XUL was back then comex already named two highly popular ones (slack in particular can't be overlooked) but there are more. https://github.com/sindresorhus/awesome-electron https://github.com/sindresorhus/awesome-electron https://electron.atom.io/apps/ https://electron.atom.io/apps/ Outside of Slack, WhatsApp and Discord (see a pattern? pretty much all new chat apps are using it), I'm not sure if there's any other truly popular (among users) electron app, but among developers, electron definitely is popular and far more often used than XUL was. It's arguably more popular now for new apps than even toolkits like Qt and WxWidgets. People are writing, not one, but multiple competing implementations of things like.. unix terminal emulators in electron. These are not just webapps contained in chrome, they definitely need native access to local APIs. There's a frenzy among devs. > so it's a stretch to say that Mozilla failed to execute on pushing XUL. What would the web gain by pushing it? They didn't fail to "push it to the web". They failed to push it to app devs. They were rather enthusiastic at some point: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/The_Joy_of_XUL https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Th... > Whether you need to migrate an existing web application to the desktop, are looking for a technology that will enable you to easily port your applications to multiple platforms, or want to integrate your own cool features into the browser, XUL warrants serious consideration. And now they are arguably failing to push it to themselves as they're entirely abandoning it for Firefox and will rewrite the UI and extensions APIs to get rid of XUL.

kibwen 10y ago
> Outside of Slack Slack has a standalone app? I've only ever used the web version. What more does it do? > Discord Likewise, I never even realized Discord had a non-browser implementation. > WhatsApp I never even realized that WhatsApp had a non-mobile implementation. > they definitely need native access to local APIs Which ones? > And now they are arguably failing to push it to themselves Er, the whole point of Mozilla is to champion standards-based web tech. They're rewriting their UI using CSS/HTML/JS because this is feasible today, whereas it wasn't in 2005. So I ask again, why would Mozilla want to retain XUL instead of making web technologies more powerful?
- M_- 10y ago
  > Likewise, I never even realized Discord had a non-browser implementation. Can't give an answer on slack, as it's not something I use (and I wouldn't use any of the three services if I had a choice, but you don't get to make choices for entire communities as an individual and chat apps are about communities..), but I can say something about discord. Custom keybindings, ability to do things like push to talk while you're in game, general integration with your OS desktop features (systemtray, native OS notifications), GUI that can overlay over your full-screen window ( like this: https://youtu.be/aVQyk_GX7aE?t=98 https://youtu.be/aVQyk_GX7aE?t=98 ) and probably other features I haven't paid attention to. > I never even realized that WhatsApp had a non-mobile implementation. http://www.theverge.com/2016/5/10/11653606/whatsapp-mac-windows-desktop-apps-download http://www.theverge.com/2016/5/10/11653606/whatsapp-mac-wind... Released in May, 2016.. and the webapp launched in 2015. > Which ones? Are you seriously asking that of terminal emulators that are supposed to be drop-in replacement for iTerm or Gnome Terminal and whatever else? how do you think your bash scripts can operate without breaking on your local data in a webapp without added native calls? I feel like I'm getting trolled here. > Er, the whole point of Mozilla is to champion standards-based web tech. They're rewriting their UI using CSS/HTML/JS because this is feasible today, whereas it wasn't in 2005. So I ask again, why would Mozilla want to retain XUL instead of making web technologies more powerful? So a great deal of selective quoting up till here while acting sassy and not paying attention to what was quoted to support the point yet still asking the question? Why would they retain a competitive edge when other platforms like electron are attracting all the developers to enhance their application with native access goodness, why indeed. I'll quote it again. > Whether you need to migrate an existing web application to the desktop [...] or want to integrate your own cool features into the browser, XUL warrants serious consideration. Is what Electron and Chrome actually do for people now, successfully, in droves and was an aspiration they had before. As for what is feasible now that wasn't before.. electron is not going away any time soon and webapps haven't replaced native. Even more so on mobile platforms, as 90% websites are begging you to install the app with full screen popups.
  - kibwen 10y ago
    > still asking the question? Yes, because the question isn't "how is this useful", it's "how is it in Mozilla's best interest to invest in this?" Mozilla came up with XUL because they wanted a cross-platform way to develop a large graphical application, and given that they're an open source organization they figured they might as well try to popularize the framework to hopefully get some volunteer contributions to the codebase. But XUL was never an end, only a means to an end, and the technology itself no longer has any strategic advantage. As for "failing to execute" on taking over the world of desktop apps with XUL, I don't think Mozilla will lose any sleep over it. The secret sauce to Electron isn't Chromium, it's Node.js. We can say that Mozilla failed to execute the opportunity to popularize server-side Javascript first... but that's Rhino was for, and really, nobody in 2005 would have foreseen that developers would eventually want to write their backends in Javascript. :P

by M_- 10y ago

kibwen 10y ago

> Outside of Slack Slack has a standalone app? I've only ever used the web version. What more does it do? > Discord Likewise, I never even realized Discord had a non-browser implementation. > WhatsApp I never even realized that WhatsApp had a non-mobile implementation. > they definitely need native access to local APIs Which ones? > And now they are arguably failing to push it to themselves Er, the whole point of Mozilla is to champion standards-based web tech. They're rewriting their UI using CSS/HTML/JS because this is feasible today, whereas it wasn't in 2005. So I ask again, why would Mozilla want to retain XUL instead of making web technologies more powerful?

M_- 10y ago
> Likewise, I never even realized Discord had a non-browser implementation. Can't give an answer on slack, as it's not something I use (and I wouldn't use any of the three services if I had a choice, but you don't get to make choices for entire communities as an individual and chat apps are about communities..), but I can say something about discord. Custom keybindings, ability to do things like push to talk while you're in game, general integration with your OS desktop features (systemtray, native OS notifications), GUI that can overlay over your full-screen window ( like this: https://youtu.be/aVQyk_GX7aE?t=98 https://youtu.be/aVQyk_GX7aE?t=98 ) and probably other features I haven't paid attention to. > I never even realized that WhatsApp had a non-mobile implementation. http://www.theverge.com/2016/5/10/11653606/whatsapp-mac-windows-desktop-apps-download http://www.theverge.com/2016/5/10/11653606/whatsapp-mac-wind... Released in May, 2016.. and the webapp launched in 2015. > Which ones? Are you seriously asking that of terminal emulators that are supposed to be drop-in replacement for iTerm or Gnome Terminal and whatever else? how do you think your bash scripts can operate without breaking on your local data in a webapp without added native calls? I feel like I'm getting trolled here. > Er, the whole point of Mozilla is to champion standards-based web tech. They're rewriting their UI using CSS/HTML/JS because this is feasible today, whereas it wasn't in 2005. So I ask again, why would Mozilla want to retain XUL instead of making web technologies more powerful? So a great deal of selective quoting up till here while acting sassy and not paying attention to what was quoted to support the point yet still asking the question? Why would they retain a competitive edge when other platforms like electron are attracting all the developers to enhance their application with native access goodness, why indeed. I'll quote it again. > Whether you need to migrate an existing web application to the desktop [...] or want to integrate your own cool features into the browser, XUL warrants serious consideration. Is what Electron and Chrome actually do for people now, successfully, in droves and was an aspiration they had before. As for what is feasible now that wasn't before.. electron is not going away any time soon and webapps haven't replaced native. Even more so on mobile platforms, as 90% websites are begging you to install the app with full screen popups.
- kibwen 10y ago
  > still asking the question? Yes, because the question isn't "how is this useful", it's "how is it in Mozilla's best interest to invest in this?" Mozilla came up with XUL because they wanted a cross-platform way to develop a large graphical application, and given that they're an open source organization they figured they might as well try to popularize the framework to hopefully get some volunteer contributions to the codebase. But XUL was never an end, only a means to an end, and the technology itself no longer has any strategic advantage. As for "failing to execute" on taking over the world of desktop apps with XUL, I don't think Mozilla will lose any sleep over it. The secret sauce to Electron isn't Chromium, it's Node.js. We can say that Mozilla failed to execute the opportunity to popularize server-side Javascript first... but that's Rhino was for, and really, nobody in 2005 would have foreseen that developers would eventually want to write their backends in Javascript. :P