Live data from Hacker News

Thank You, Firebug (2017)

getfirebug.com

71–80 of 89 posts

Re: Thank You, Firebug (2017)

#71

Earlier quoted context omitted.

Isn't Web 2.0 the web with user-contributed content, i.e. social media? For me, being part of Web 2.0 would not be something to be proud about, it's the tech that brought uninformed, angry populist rage online...

I think Web 2.0 was more when the web became more interactive. Instead of only static web pages there were forums, UIs that responded to your actions, and early social networks (but not the modern monsters we currently have). It enabled them, but it wasn't strictly "Web 2.0".

Yes, Web 2.0 is about XHR and interactive UIs.

That said, even at the time the definition was not really clear. I remember a joke, why Web 2.0 is like teen sex... Everyone is talking about it, almost noone is doing it, and even those that are, are probably doing it wrong.

Fun times. You could change the image without reloading the page. Woohoo!

Re: Thank You, Firebug (2017)

#72

Earlier quoted context omitted.

"Too battery-inefficient, too laden with security holes." Lol. The reason Apple didn't support Flash was it was too good. If flash was supported 100% (practically natively) - there would be no point creating native apps in objective C (Flash was a full decade ahead). Flash devs would have coded circles around objective C devs. This could have screwed over the entire ios ecosystem. Once flash was dead and gone: SWIFT!

> The reason Apple didn't support Flash was it was too good. The competition with native may have been part of the consideration, but this was far from the full argument. It was also much too bad . It was power hungry, as noted by others, because flash content tended to be driven by a million timers, but also, its interaction model was a disaster on touch screens. Even on desktop, one of the problems with Flash conte…

The other perspective to add is historic: in the early days of the Macintosh Apple helped make Adobe Type 1 Fonts a printing standard and a deep OS level font standard and then Apple had a long relationship of depending on Adobe for binaries for Adobe Type Manager for core OS experiences. Adobe Type Manager had a long and interesting history, including and in particularly its huge share of OS-level, kernel breaking vulnerabilities. In OS X Apple paid Adobe to finally get the source code for ATM so they could do their own vulnerability reviews and own that code locally. Presumably at great cost.

(Aside: Microsoft got caught in the same proprietary "standards" problem having to ship Adobe Type Manager with Windows for just about the entire history of Windows and then eventually paying Adobe enough to get to the source code and fork their own version of it that they could entirely own for vulnerability scanning while maintaining backwards compatibility. Also presumably at great cost.)

It certainly seems easy to understand why Apple might have been hesitant to depend on yet another proprietary binary drop from Adobe as core OS service in iOS had they embedded Flash into iOS Safari given that expensive history already with Adobe Type Manager.

(Adobe may have indirectly killed Flash just by that history/reputation of being a bad, expensive vendor with tons of vulnerabilities and charging Apple and Microsoft an arm and a leg to fix those vulnerabilities.)

Re: Thank You, Firebug (2017)

#73

Earlier quoted context omitted.

Lots of alerts and console prints. Which sucked, but the modern tools support the giant monstrosities of today. So not a complete win.

Actually, console.print was a later addition - when I started looking at Javascript, you could only do alerts, or you could call "status" to display something in the lower part of the frame. And if you accidentally alert()-ed inside a loop... Still, I can't comprehend how you could develop anything in Javascript with just console.print either. You have my respect and admiration.

I remember there being a console window in the late 90s... don't remember what the full functionality was at the time however. Maybe it only showed warnings/exceptions?

It wasn't too dissimilar to developing a gui app, you could print to the console, raise a dialog, or if you wanted to be fancy implement a log with a window or pane to show them. Logging is what I use today for backend systems. It is usually enough, only breaking out a debugger once or twice a year.

Re: Thank You, Firebug (2017)

#74
post #15

Earlier quoted context omitted.

Can't you click on the filename/number on the right hand side? That works for me in Chrome. Source maps even allow it to open to the correct file inside Chrome.

I think they mean: function addStuff(a, b) { return a + b; } function logFunction() { console.log(addStuff); } logFunction(); And have it log out that `addStuff` is defined on line 1.

In Edge Dev Tools (so I'm sure it is similar in Chrome Dev Tools) it doesn't show source/line information in the log message directly (though it does have a link to the source line for the console.log message on the far right), but right-clicking a logged function includes a context menu choice for "Show function definition" which will jump to addStuff's declaration on line 1.

Re: Thank You, Firebug (2017)

#75

An interesting convention that ~started with Firebug was the use of angle brackets in the DOM/Elements view. (eg a DIV element is shown as ` `). HTML, as a text format, uses angle brackets to denote tags. But DOM is an in-memory object model; it doesn't have tags, but elements, and those have nothing do with angle brackets (other than getting el.innerHTML will serialize back). From a usability POV, it's entirely defe…

Wow, I remember that cheatsheet was really handy! Thanks for that.

I still google "box sizing paul irish" every now and then to get to your blog… I can hardly believe it has been 10 years since you published that, time flies.

Re: Thank You, Firebug (2017)

#76
My former employer is still using HTA (HTml Application) to dynamically render a lot of tool windows in their massive legacy COM application on Windows. HTAs render using an IE6-era renderer that is still present in Windows. (I wasn't in the group that built these tool windows, but I did build a lot of in-house web apps to help with various workflows.)

A few years ago, I had a colleague come by with bug he couldn't solve in an HTA tool window. There's no built-in console or anything... but I showed him how to copy/paste the Firebug Lite minified JS into a tag, and how he could then press F12 to bring up Firebug Lite inside the HTA tool window. (Note Firebug Lite supported IE all the way back to 6). He was able to quickly debug & resolve the problem.

Thanks Firebug!

Re: Thank You, Firebug (2017)

#77
post #59

Earlier quoted context omitted.

Exactly that. When Mozilla started reimplementing it, it seemed somehow error stack traces started breaking for both firebug and the horrible builtin developer tools That's when we switched to Chrome for debugging, and only come back to Firefox to debug endless loops and stack overflows (because their Javascript VM is still better at being able to suspend/trace those)

Yup. It is quite incredible how many times Mozilla shot itself.

Well, Mozilla itself was the result of a failed attempt at a rewrite. Jamie Zawinski decided that being a bar owner was a better career option shortly after that experience.

It’s hard to tell with autodidacts if they really got pissed off about something or just needed an excuse to deep dive into something completely unrelated, and I would definitely peg him as one.

Re: Thank You, Firebug (2017)

#78

An interesting convention that ~started with Firebug was the use of angle brackets in the DOM/Elements view. (eg a DIV element is shown as ` `). HTML, as a text format, uses angle brackets to denote tags. But DOM is an in-memory object model; it doesn't have tags, but elements, and those have nothing do with angle brackets (other than getting el.innerHTML will serialize back). From a usability POV, it's entirely defe…

The pseudo-source view also came (and still comes) with noticeable performance drawbacks. Opening the inspector on a nested element using today's browsers' built-in inspectors (which are implemented in HTML nowadays) can be slower than if you were to do the same thing on the same graph with a Web development extension in Firefox, since extensions were able to use the XUL platform, and that meant being free to implement nsITreeView.

And that's even with the advantage of modern hardware and and the trick where modern development tools will choose to elide elements in favor of showing a message that says that some nodes are hidden, with a button to e.g. "Show all 347 nodes". I just tried this with a 5000-row table, and clicking the "Show all[...]" button in Firefox's built-in developer tools has seemingly no effect at first—the inspector appears appears unresponsive for several seconds, before finally painting the expansion. In programs from 15 years ago running on 15+ year old hardware, on the other hand, this could expected to be nearly instant.

Jamie Brandon recently complained about this sort of thing, comparing the experience of creating an information-dense UI using imgui versus doing the same "on the web" (i.e. in the browser, using HTML):

https://www.scattered-thoughts.net/log/0026/>

Re: Thank You, Firebug (2017)

#79

My former employer is still using HTA (HTml Application) to dynamically render a lot of tool windows in their massive legacy COM application on Windows. HTAs render using an IE6-era renderer that is still present in Windows. (I wasn't in the group that built these tool windows, but I did build a lot of in-house web apps to help with various workflows.) A few years ago, I had a colleague come by with bug he couldn't s…

Microsoft themselves ended up doing something like this—VorlonJS. https://github.com/MicrosoftDX/Vorlonjs>

There's also weinre https://people.apache.org/~pmuellr/weinre/>, which is the same with the (old) WebKit Inspector code, rather than Firebug.

Re: Thank You, Firebug (2017)

#80

On this topic, and Chrome Dev Tools, does anyone else struggle with getting access to the state of their app? I find that because of all the encapsulation and transpilation tricks, it’s basically impossible to get a hold of my state or functions in the dev tools during runtime. The best I can do is forcibly set window.state and do a bit of work. I can set breakpoints and do all that stuff. But I remember back in the…

It's a known problem, especially with the move away from self-styled OOP paradigms and the rise of closure-infested programming. (I.e., "OOP, but with closures—and which (for overall very bad reasons) we're going to insist on describing as FP".)

Recent thoughts by one of the Eve/Light Table developers:

https://www.scattered-thoughts.net/writing/coding/>

(Ctrl+F on "hard-to-query state" and "reachable".)

Post reply on HN