6 ms·

Am I the only one that finds it amusing that a JS debugger is called debugger.html? debugger.DOM, sure, .JS even, but .html?

by daenney 10y ago

acemarke 10y ago
I 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 ago
  It's being built with JS (React) widgets.
  - acemarke 10y ago
    Right, 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 ago
      The 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 ago
        Modern web technologies as opposed to XUL, the previous UI layer, which is ancient and very decidedly non-web.
      - eyelidlessness 10y ago
        DOM is specified in HTML.
      - exogen 10y ago
        You'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 ago
        No, 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 ago
        Yes, 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.
        Touche 10y ago
        Ok, you consider a canvas app to be an html app. We simply don't define html the same way; you seem to define it as anything that runs in a web browser. I define it as a markup language. Too far apart on this one, time for me to move on.
        Etzos 10y ago
        I think you've missed the point being made here. What's being said seems to be that regardless of how much scripting/API calls there are, if the base is HTML then it is HTML. To paint this another way, let's say you have UI toolkit "X" which defines elements using YAML but also provides a programmatic API in your favorite programming language to add, remove, modify, or otherwise modify elements. Now let's say there is another UI toolkit "Y" which defines elements using XML but, like toolkit X, it also provides a similar API. Regardless of how many YAML elements you explicitly create you've used X and not Y, in fact you've used YAML and not XML. It doesn't really matter if >50% of your code is using the API or not, just that you've used some amount of YAML. That's exactly the situation here: the existing debugger interface is using XUL and this new version is using HTML. Even if there wasn't a single line of HTML code, it would still be using the DOM to generate HTML and not XUL--and that's the distinction being made.
mintplant 10y ago
There'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
- sangnoir 10y ago
  I think gp meant that one would expect the project to be called debugger.js instead.
  - mintplant 10y ago
    But the current debugger is already built with JS, using the XUL renderer. debugger.html uses the HTML renderer.
clarkbw 10y ago
The 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 ago
It'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 ago
  I 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 ago
I 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.

Am I the only one that finds it amusing that a JS debugger is called debugger.html? debugger.DOM, sure, .JS even, but .html?

by daenney 10y ago

Am 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 ago

I 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 ago
It's being built with JS (React) widgets.
- acemarke 10y ago
  Right, 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 ago
    The 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 ago
      Modern web technologies as opposed to XUL, the previous UI layer, which is ancient and very decidedly non-web.
    - eyelidlessness 10y ago
      DOM is specified in HTML.
    - exogen 10y ago
      You'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 ago
        No, 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 ago
        Yes, 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.
        Touche 10y ago
        Ok, you consider a canvas app to be an html app. We simply don't define html the same way; you seem to define it as anything that runs in a web browser. I define it as a markup language. Too far apart on this one, time for me to move on.
        Etzos 10y ago
        I think you've missed the point being made here. What's being said seems to be that regardless of how much scripting/API calls there are, if the base is HTML then it is HTML. To paint this another way, let's say you have UI toolkit "X" which defines elements using YAML but also provides a programmatic API in your favorite programming language to add, remove, modify, or otherwise modify elements. Now let's say there is another UI toolkit "Y" which defines elements using XML but, like toolkit X, it also provides a similar API. Regardless of how many YAML elements you explicitly create you've used X and not Y, in fact you've used YAML and not XML. It doesn't really matter if >50% of your code is using the API or not, just that you've used some amount of YAML. That's exactly the situation here: the existing debugger interface is using XUL and this new version is using HTML. Even if there wasn't a single line of HTML code, it would still be using the DOM to generate HTML and not XUL--and that's the distinction being made.

mintplant 10y ago

There'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

sangnoir 10y ago
I think gp meant that one would expect the project to be called debugger.js instead.
- mintplant 10y ago
  But the current debugger is already built with JS, using the XUL renderer. debugger.html uses the HTML renderer.

clarkbw 10y ago

The 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 ago

It'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 ago
I 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 ago

I 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.