16 ms·
Introducing the Firefox debugger.html
- daenney 10y agoAm I the only one that finds it amusing that a JS debugger is called debugger.html? debugger.DOM, sure, .JS even, but .html?
- acemarke 10y agoI think the comparison is that most of the Firefox UI has traditionally been built with XUL components, whereas this part is being built with HTML elements instead.
- Touche 10y agoIt's being built with JS (React) widgets.
- acemarke 10y agoRight, just saying that the underlying render target is HTML rather than XUL. The "CONTRIBUTING" file actually calls that out: > The name debugger.html was chosen because this debugger interface is being written using modern web technologies where as the previous Firefox debugger was written in XUL.
- Touche 10y agoThe underlying renderer targets DOM Nodes. I'm not sure if I would say DOM Nodes === HTML or not. I think of HTML as the thing I write in .html files. but whatever, mostly semantics here. I would disagree that debugger.html was written using modern web technologies. It was written using one web technology but rejects many others, like html written in html, the `<template>` tag, web components, etc.
- mintplant 10y agoModern web technologies as opposed to XUL, the previous UI layer, which is ancient and very decidedly non-web.
- eyelidlessness 10y agoDOM is specified in HTML.
- exogen 10y agoYou're basically saying no site/app is ever written using modern web technologies unless it forgoes any framework usage, using every "vanilla" browser feature where possible. The HTML5 spec even says: "The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM." and: "[HTML] implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces." This debugger is 100% web technology and describing it as "HTML", the rendering platform it targets, is 100% accurate. The fact that it's written using React does not change this in the slightest.
- Touche 10y agoNo, I'm saying an app that doesn't use html is not an html app. This app has a total of 13 lines of html: https://github.com/devtools-html/debugger.html/blob/master/index.html https://github.com/devtools-html/debugger.html/blob/master/i... An app that uses canvas is an html app too, by your definition; as the existence of dom nodes is apparently === html. This is a web app, sure.
- exogen 10y agoYes, canvas is an HTML element and so would be an HTML app. You seem to be caught up on how much serialized HTML there is. The serialization is one tiny, tiny part of the HTML spec.
- 10y ago
- mintplant 10y agoThere's another Mozilla project called "browser.html" which is a browser UI built with web technologies. "debugger.html" is a similar idea. https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml
- clarkbw 10y agoThe Firefox DevTools team is moving away from XUL, so the .html suffix is a wink to moving to HTML.
- deleted 10y ago[deleted]
- Touche 10y agoIt's amusing because there's hardly any html. Instead of using platform features like template it uses a meta-framework that seeks to make html an implementation detail. This could just as well have been written to a canvas. This is a JS project, not an html project.
- txutxu 10y agoI see the point, did think the same when reaching "npm install" it's like gcc -o a.out something.html But there are teams dedicated to the "image" of opensource projects, and people that needs to collaborate that ways, creating wordings... like: > The debugger.html project is hosted on GitHub and uses modern frameworks and toolchains, making it readily available and attractive to a wide audience of... Of developers. We as developers, at the end of the day, are humans. And image branding, helps to projects adoption. Not always and not only. But it helps. By other comments, that ".html" sounds like those ".io" or ".me" domains... a way of bring an ip response to you in 2016. Javascript and CSS, is the 90% codebase intention of those HTML browsers that we use. (And binary size). It could have been worse... usually we need a .html to load many .js (and moar stufz)... hey, it's related. They could have call it an unrelated extension like .ninja or more confusing, related to computing, but unrelated to html/js, something like SOMETH~1.TXT You never know :)
- sundarurfriend 10y agoI find it amusing that this is the second-longest comment subthread in this page, proof of the bikeshed theory of discussions: because it's about superficial naming stuff, everyone is happy to chime in and have an opinion.
- ars 10y agoI don't know if anyone from the team is reading this, but I'll tell you want I want from a Javascript debugger: I want to be able to modify/add code, try it out, then rewind, and try something else. Then save my changes once they work perfectly. Simply setting breakpoints and watching variables is nice, but I can do basically the same thing by echoing/console.log'ing things. If you are going to go to the effort of making a debugger, then make it do something I can't do another way.
- espadrine 10y agoThe following bug may be of interest to you: https://bugzilla.mozilla.org/show_bug.cgi?id=1207696 https://bugzilla.mozilla.org/show_bug.cgi?id=1207696 It will support replaying and help go towards rewinding, although live code editing is not in there.
- mintplant 10y agoWebReplay! One of the coolest projects at Mozilla right now, IMO. You can record and rewind the entire state of the browser and do reverse-stepping etc like with rr. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
- renke1 10y agoSaving changes may be a bit harder these days with all the transpiling going on.
- BinaryIdiot 10y agoThat's something the community will simply have to deal with. Transpiling already creates issues when you're debugging code since what you debug is different than what you wrote. Honestly this is one of the biggest issues I have with transpiling everything; you don't have to transpile even though our industry seems to be standardizing on it.
- revelation 10y agoThat's because integrated debuggers are a rather crass design error. Windows doesn't come with a debugger. Linux doesn't come with a debugger. The JVM has no right-click launched debugger. CPython doesn't jump you into an interactive debug console. But all of those have a debug interface. Leave building debuggers to others who have a clear picture of how they are using your platform.
- zimbatm 10y agoPretty impressive for a project that started end of March! (first commit timestamp)
- mbrock 10y agoTo me that's consistent with the productivity boost I've experienced from React-like web programming (YMMV).
- iamcreasy 10y agoI've seen the word 'React' showing up lot after Facebook released their React Javascript library. Is the that library is somehow related to what you are referring to? I don't do any web programming, so can you explain simple what it means by 'react' or 'react like'? What is Reactive programming?
- clarkbw 10y agoThe debugger landed in Nightly today, its not quite ready for prime time yet but on by default and getting updated regularly. https://nightly.mozilla.org/ https://nightly.mozilla.org/
- iyn 10y agoTalk about the refactoring from React Rally: https://www.youtube.com/watch?v=Fk--XUEorvc&t=8542s https://www.youtube.com/watch?v=Fk--XUEorvc&t=8542s (starts at 2:22:22)
- clarkbw 10y agoThat's James Long, lead engineer for the project. He gives a great demo of the debugger.html integration with Emacs. :)
- mikegirouard 10y agoI'm sure it's been considered already, but I'm immediately concerned about the security implications of running a node server when debugging. Perhaps that is only the case when debugging in a stand-alone setup? Think if you RDP to Firefox or Chrome and forget that the server is running. Does that mean that if I browse to http://your.machine:8000 http://your.machine:8000 that I can control your browser?
- Karunamon 10y agoOuch.. yeah. If there is the slightest degree of sanity in the world, that server is bound to 127.0.0.1 and not the external interface (with appropriate hoops to jump through if you want to change it)
- edibleEnergy 10y agoIt is bound to all interfaces as of the current commit: https://github.com/devtools-html/debugger.html/blob/7c002fdc69a6b54a04b5a292f2cb782ddf51fe58/bin/development-server.js#L86 https://github.com/devtools-html/debugger.html/blob/7c002fdc... Generally the sanest default for that value is 127.0.0.1 and changeable via a cli option.
- cptskippy 10y agoI believe it's done this way to facilitate remote debugging on mobile devices or node servers.
- clarkbw 10y agoThis is only for development of the debugger itself and shouldn't be used for a production release. Within Firefox there is no node process it is run purely as a web application.
- mikegirouard 10y agoThat makes sense. I figured that there was most likely two different run modes (in browser vs stand-alone). Thanks for clarifying.
- edibleEnergy 10y agoVery cool, looking forward to getting a deeper look at the source code. Nice work!
- sunilkumarc 10y ago'.html' in the name makes it sound like a not so important product from Firefox. I think they could've chosen a better name.
- millerm 10y agoI think it's a naming convention for their new product offerings, based on their new technology stack. Servo's UI is named "browser.html"(https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml)
- XCSme 10y agoSo, is it better than the Chrome built-in debugger? :D
- partizanos 10y agoAnother feature I was trying to find was a way to see the history log of changes of a variable and the lines where it happened, between two program states.
- jasonlaster11 10y agoI like that idea. I think we can do several things when it comes down to tracking changes: * make it easier to pause when a reference is set/get * make conditional breakpoints more of an every-day experience * better symbol search so that it is easier to see the different variable references and add the right breakpoints
- partizanos 10y agoOf course it's trackable with the use of traditional breakpoints but in big applications with a lot of dependencies step by step approach (through different scopes where the variable changes names) could take long time. But yes the good practises you mention make it easier.it's just something I Would like to see automated.
- aikah 10y agoI'd say just look at Chrome dev tools and copy them at this point. Debugging in Firefox is a mediocre experience IMHO. As for the name .html is unnecessary.
- clarkbw 10y agoTo be honest, it feels like you didn't actually look at the link.
- aikah 10y agoI actually did. And I saw nothing that made me think it would make my debugging experience better.
- SwellJoe 10y agoSo, what does Chrome dev tools provide that current Firefox does not? I use Firefox because it's what I've always used (and I prefer the browser) and what I'm familiar with. What are the good reasons for me to learn the Chrome dev tools?
- mschuster91 10y ago1) Speed. Chrome is blinking fast, Firefox, especially when fiddling with margins on CSS classes that are heavily used, is dog slow. 2) Compatibility with Webkit-based mobile browsers for debugging. I'm so not having two browsers with hundreds of MB of RAM usage open. Firefox' advantage is, though, the mouse inspector - it shows rulers for the selected element at it's borders. Invaluable when trying to align text across columns or rows!
- SwellJoe 10y ago1. I haven't found Firefox to be "dog slow". I may not be doing things that stress it, but overall, speed is not something I have had complaints about. 2. Ummm...don't you have to test against non-WebKit browsers, anyway? Or, do you really expect all of your users to only use WebKit based browsers? That seems problematic.
- lol768 10y agoIs 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 agoI 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.
- garaetjjte 10y agoOh no. Why there is a trend to write browser components in HTML and JS?
- mintplant 10y agoMuch of the Firefox UI is and has been written in JS for a long, long time. What's happening now is that Mozilla is moving some components away from the XUL renderer -- an old, crusty piece of tech that is only still maintained because Firefox depends on it -- to the HTML renderer. Having more things on one stack means development resources can be spent more effectively.
- deleted 10y ago[deleted]
- rattray 10y agoHow do people currently debug node code? Is this a major or minor advance in that world?
- mikewhy 10y agoNode has a built-in debugger that works with Chrome Dev Tools. There's also Node Inspector that does the same. Another option is some IDEs.
- dman 10y agoAny chances of using this as a frontend to lldb/gdb for c/c++ debugging?
- mathiasrw 10y agoAny good reason they have not published via npm?