3 ms·

Mozilla has very poor justification as to why. It's not like they have a light-weight cross-platform UI framework to build their applications with, much like th

Mozilla has very poor justification as to why. It's not like they have a light-weight cross-platform UI framework to build their applications with, much like their web browser should be.

pjc50 8y ago
... what happened to XUL?
- franga2000 8y ago
  XUL and Mozilla are like DOS and Microsoft. It's old and broken, but no matter how much they try to get rid of it, some bit of it always survives.
- dralley 8y ago
  Poorly documented, implementation-defined, fragile, in-house only, etc. Mozilla can't hire anyone with deep knowledge of XUL to maintain XUL, and they can't assume the current generation of experts will be around forever. They're trying to get rid of it. Writing more of it as anything but a stopgap would be counter to their current goals.
rexpop 8y ago
You think browser teams should develop UI frameworks?
- pcwalton 8y ago
  Browser developers are literally in the business of developing UI frameworks. :)
- techntoke 8y ago
  Uh, yeah... I think that is pretty much what the main modern web browsers are at this point. A UI framework to render hypertext markup and stylesheets, and then a very crappy language known as JavaSuck to break things and spy on people.
- devwastaken 8y ago
  Every browser creates their own UI framework. They just don't want anyone to make software with their stuff unless its made for their specifically marketed purpose, web sites. Firefox used to have XUL, still completely does, but they removed the ability for XULRunner API's that worked pre-57. Firefox's UI is still very much XUL, and it's a very slow process for them changing it to 'Web Components'. You actually still can create specific components using XUL and make your own stuff, just that it'll break at any moment. They hid the decision to remove browser application extensibility behind 'web extensions' and refuse to acknowledge how they screwed over devs that relied upon it, and have a significant failure of the potentials of browser technology. There is a big difference between an extension in a browser, and extending the browser itself. If there was a browser right now that could have its UI replaced in a standard way and updated just like the normal browser, most electron apps would not be required. It'd be far safer, performant, and would solve a lot of the big problems in the web app as a desktop app ecosystem. However, that's not their market. All browsers are in this for market. This is not a new development either. Look at the JSApi for SpiderMonkey and they'll purposefully break compatibility on any and all versions. They don't understand what an API means. You can look at WebAssembly, too. There is no engine you can use to run independent wasm from mozilla, even though mozilla are the ones who pushed the spec which includes many claims outside of browser usage that Mozilla never persued. At the end of the day Mozilla does not deliver on their ideas or technology unless it's firefox or something related. If you ever want to use 'web technology' in your own applications you will end up using Webkit. Which I think is super funny given that's Apple.
  - techntoke 8y ago
    I agree 100%, however WebKit isn't the only solution. Even Qt now uses Chromium from my understanding: https://wiki.qt.io/QtWebEngine https://wiki.qt.io/QtWebEngine I think CSS is pretty great, but I would like to see something like Sass/Jade/Mustache/etc rendered client side. If browsers would focus less on JavaScript, and more on improving markup languages under the core Unix Philosophies, then we wouldn't be where we are today. I hope eventually they will let containers or the API in Linux handle permissions/security, and improve that. Android has it's own issues with Java. With Vulkan, Linux is ready for a very efficient and ever-evolving scalable solution. Heck, a modern UI scripting framework for the terminal similar to kmscon would be incredible. No reason the terminal can't support markup and assets. My vision is something similar, but definitely more friendly than DolDoc: https://news.ycombinator.com/item?id=13962436 https://news.ycombinator.com/item?id=13962436

Mozilla has very poor justification as to why. It's not like they have a light-weight cross-platform UI framework to build their applications with, much like their web browser should be.

pjc50 8y ago

... what happened to XUL?

franga2000 8y ago
XUL and Mozilla are like DOS and Microsoft. It's old and broken, but no matter how much they try to get rid of it, some bit of it always survives.
dralley 8y ago
Poorly documented, implementation-defined, fragile, in-house only, etc. Mozilla can't hire anyone with deep knowledge of XUL to maintain XUL, and they can't assume the current generation of experts will be around forever. They're trying to get rid of it. Writing more of it as anything but a stopgap would be counter to their current goals.

rexpop 8y ago

You think browser teams should develop UI frameworks?

pcwalton 8y ago
Browser developers are literally in the business of developing UI frameworks. :)
techntoke 8y ago
Uh, yeah... I think that is pretty much what the main modern web browsers are at this point. A UI framework to render hypertext markup and stylesheets, and then a very crappy language known as JavaSuck to break things and spy on people.
devwastaken 8y ago
Every browser creates their own UI framework. They just don't want anyone to make software with their stuff unless its made for their specifically marketed purpose, web sites. Firefox used to have XUL, still completely does, but they removed the ability for XULRunner API's that worked pre-57. Firefox's UI is still very much XUL, and it's a very slow process for them changing it to 'Web Components'. You actually still can create specific components using XUL and make your own stuff, just that it'll break at any moment. They hid the decision to remove browser application extensibility behind 'web extensions' and refuse to acknowledge how they screwed over devs that relied upon it, and have a significant failure of the potentials of browser technology. There is a big difference between an extension in a browser, and extending the browser itself. If there was a browser right now that could have its UI replaced in a standard way and updated just like the normal browser, most electron apps would not be required. It'd be far safer, performant, and would solve a lot of the big problems in the web app as a desktop app ecosystem. However, that's not their market. All browsers are in this for market. This is not a new development either. Look at the JSApi for SpiderMonkey and they'll purposefully break compatibility on any and all versions. They don't understand what an API means. You can look at WebAssembly, too. There is no engine you can use to run independent wasm from mozilla, even though mozilla are the ones who pushed the spec which includes many claims outside of browser usage that Mozilla never persued. At the end of the day Mozilla does not deliver on their ideas or technology unless it's firefox or something related. If you ever want to use 'web technology' in your own applications you will end up using Webkit. Which I think is super funny given that's Apple.
- techntoke 8y ago
  I agree 100%, however WebKit isn't the only solution. Even Qt now uses Chromium from my understanding: https://wiki.qt.io/QtWebEngine https://wiki.qt.io/QtWebEngine I think CSS is pretty great, but I would like to see something like Sass/Jade/Mustache/etc rendered client side. If browsers would focus less on JavaScript, and more on improving markup languages under the core Unix Philosophies, then we wouldn't be where we are today. I hope eventually they will let containers or the API in Linux handle permissions/security, and improve that. Android has it's own issues with Java. With Vulkan, Linux is ready for a very efficient and ever-evolving scalable solution. Heck, a modern UI scripting framework for the terminal similar to kmscon would be incredible. No reason the terminal can't support markup and assets. My vision is something similar, but definitely more friendly than DolDoc: https://news.ycombinator.com/item?id=13962436 https://news.ycombinator.com/item?id=13962436