4 ms·

Is this expected to be faster than the XUL based stuff? Currently "React" to me makes me think poor performance, simply due to bad experiences I've had with web

by lol768 10y ago

Is this expected to be faster than the XUL based stuff? Currently "React" to me makes me think poor performance, simply due to bad experiences I've had with web applications and 'native applications' (read: web browser wrappers). Surely there's going to be overhead using the remote debug protocol, it looks like it's built on JSON so every response is going to need to be deserialised? I can understand that it's nice to have the official tools using the same APIs that external tools would use, though (and supporting multiple targets is a nice benefit). Further (and this is perhaps less on-topic), why do all UIs need to be written in HTML/CSS these days to be considered "modern"? More broadly speaking, is a GTK or Qt interface going to be less performant than something using a browser engine? The motivation I've seen at a lot of companies seems to be that they already have web designers who can design web pages, and so these people are put to work designing desktop applications too. That's all well and good, but it seems to often result in a poor user experience and be visually different from the rest of the OS.

Etzos 10y ago
I don't think the plan is for it to be faster necessarily, but rather to move the existing tools off of a technology they are (slowly) moving away from. While there will be some overhead due to the use of React I doubt it will be anything noticeable. In fact, I just checked it out in the Nightly version of Firefox and it doesn't feel any slower than the previous version of the debugger. As for the remote debugging protocol, I don't think that will really cost much of anything. The debugger itself is using Javascript so the deserialization cost of JSON is pretty much nonexistent on that end. As for everything needing to be written in HTML/CSS, this seems like an odd place to bring that up as this is quite literally a tool found inside of a web browser. As a whole though, I think HTML/CSS "apps" are cropping up largely because there are so many people familiar and comfortable with the technology, not because it's seen as more performant. And now that things like Electron and NW.js exist, it's trivial to leverage that knowledge to make a UI which uses it verses having to learn a new language/framework.
dpacmittal 10y ago
> Further (and this is perhaps less on-topic), why do all UIs need to be written in HTML/CSS these days to be considered "modern"? Because there are a lot of web developers who want to make a desktop app without having to learn C++. Not to mention there are a lot more web developers than C++/Qt/any-other-technology developers in general.
Sylos 10y ago
At least, it sort of makes sense to do inside a browser, as you don't need to load in an entire web browser as a library. Also just in general, the long-term plan for Firefox is to phase out XUL and to replace it with HTML/CSS/JS, so this is not just someone choosing to write their application in web technologies for no reason, but means that they will actually have less maintenance work.
sfink 10y ago
Writing in HTML/CSS gets you some of the benefits of the Web, eg cross-platform, portability, backwards compatibility, an active base on which to develop (new web standards are being developed all the time). It's also familiar to a larger pool of developers, which I agree isn't the greatest argument if your goal is quality. Don't underestimate the power of working on top of a platform that is being actively worked on and improved by a large pool of developers. Even if the platform has large deficiencies compared to some other platform, the rate of progress is going to make the Web win eventually, as long as you don't look at very specific metrics that happen to be Web pain points. (cf "Always bet on JavaScript") As for fitting in with an OS's look and feel, that is indeed a current weakness of HTML/CSS, but there is energy behind fixing that (eg with Mozilla's desire to move away from XUL). So it's one of those things that will happen slower than you want in the near term, but faster than you expect in the long term.

by lol768 10y ago

Etzos 10y ago

I don't think the plan is for it to be faster necessarily, but rather to move the existing tools off of a technology they are (slowly) moving away from. While there will be some overhead due to the use of React I doubt it will be anything noticeable. In fact, I just checked it out in the Nightly version of Firefox and it doesn't feel any slower than the previous version of the debugger. As for the remote debugging protocol, I don't think that will really cost much of anything. The debugger itself is using Javascript so the deserialization cost of JSON is pretty much nonexistent on that end. As for everything needing to be written in HTML/CSS, this seems like an odd place to bring that up as this is quite literally a tool found inside of a web browser. As a whole though, I think HTML/CSS "apps" are cropping up largely because there are so many people familiar and comfortable with the technology, not because it's seen as more performant. And now that things like Electron and NW.js exist, it's trivial to leverage that knowledge to make a UI which uses it verses having to learn a new language/framework.

dpacmittal 10y ago

> Further (and this is perhaps less on-topic), why do all UIs need to be written in HTML/CSS these days to be considered "modern"? Because there are a lot of web developers who want to make a desktop app without having to learn C++. Not to mention there are a lot more web developers than C++/Qt/any-other-technology developers in general.

Sylos 10y ago

At least, it sort of makes sense to do inside a browser, as you don't need to load in an entire web browser as a library. Also just in general, the long-term plan for Firefox is to phase out XUL and to replace it with HTML/CSS/JS, so this is not just someone choosing to write their application in web technologies for no reason, but means that they will actually have less maintenance work.

sfink 10y ago

Writing in HTML/CSS gets you some of the benefits of the Web, eg cross-platform, portability, backwards compatibility, an active base on which to develop (new web standards are being developed all the time). It's also familiar to a larger pool of developers, which I agree isn't the greatest argument if your goal is quality. Don't underestimate the power of working on top of a platform that is being actively worked on and improved by a large pool of developers. Even if the platform has large deficiencies compared to some other platform, the rate of progress is going to make the Web win eventually, as long as you don't look at very specific metrics that happen to be Web pain points. (cf "Always bet on JavaScript") As for fitting in with an OS's look and feel, that is indeed a current weakness of HTML/CSS, but there is energy behind fixing that (eg with Mozilla's desire to move away from XUL). So it's one of those things that will happen slower than you want in the near term, but faster than you expect in the long term.