> I'm using Firefox for all my personal browsing, but I decided to spin up Chrome because I know how good their DevTools are. So make sure to use the right tool for the job.
Are Firefox's devtools actally worse then Chrome's though?
It's a tough set of tradeoffs. Chrome has more features here and there but (for example) the Firefox profiler gives MUCH more detailed and useful information if your goal is to figure out where your CPU time is going.
The chrome profiler is also incredibly slow, I suspect because the Chrome dev team rarely uses it and hasn't had to optimize it (they have a different profile viewer for things like tracing browser execution). The FF profiler is the main one the FF dev team uses, so in practice it's much faster. For that reason also it has profile sharing built in, which is handy.
I really like Firefox's dev tools layout. I have to agree with the sibling comment on the "network" tab though. For some reason, Chromium has given me more detailed error messages about requests, which have guided me in the right direction when Firefox left me scratching my head a bit.
I wonder if discord can now be the subject of the EU interop directive. Namely, core communication functions should be available in open, simple (but good enough to do the job) and stable in time protocols. I guess, some core subset of xmpp should do the trick (or maybe even simpler, namely without xml?)
The bit which is troublesome is account creation. Namely, it should be possible with a noscript/basic (x)html browser.
Now I wonder how they "filter" click farms (with humans or human trained mouse/keyboard AIs on blink/geeko/webkit) via swarms of compromised devices or via public VPNs.
A wild guess: post creation account behavior should give in enough hints at an account being "fake" or not. People with false positive won't be happy though.
There are already reimplementations of the client side of some of their protocols (which are just JSON HTTP requests), including account registration, without running any JavaScript (parsing the JS is needed though). These are of course against the ToS and can get you banned though.
The EU directive is supposed to do exactly that: protect against those abusive TOS and technical interop blockade (closed protocols, forcing ppl to use beyond sanity complex and huge software).
Not that this isn't a very interesting point re: open systems, I fail to see how it's relevant to the post, which is clearly just reverse engineering a "party mode" feature which was made as part of 7th Discord's birthday.
I implemented a fair amount of XMPP for a web client back around 2012, and I gotta say, the XML wasn't a problem, at all. Actually the whole thing was a lot easier than comments about how awful XMPP is might lead one to expect—I know a lot of the complexity is in extensions, which I barely touched (but some!), but some people paint the whole protocol as unworkably bad, and that's simply not true.
As for the XML side of it in particular, XML compresses well, isn't slow to write by hand with modern editor features, and working with it in a browser is great because—and maybe this isn't common knowledge?—you can tell the browser to build a DOM out of XML, not just html, so you can let it handle parsing and constructing or modifying messages, meaning you can get pretty damn far implementing XMPP with surprisingly few lines of code and no external libs.
Indeed. I work with XMPP daily and share your views. However XML can be horrific, and I do dread working with it in many applications (remember SOAP?). I assume people transfer these experiences easily.
One thing that can be annoying is that some environments don't have streaming ("SAX") parsers readily available. That's less of a problem these days, but framing would have helped implementers in that regard. However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing.
> Indeed. I work with XMPP daily and share your views. However XML can be horrific, and I do dread working with it in many applications (remember SOAP?). I assume people transfer these experiences easily.
Oh, sure, XML can be a nightmare, it was just good enough in XMPP's case that I doubt anything else would have been much easier/better. There were some minor annoyances and awkwardness, but that's hard to completely eliminate in that kind of thing. Its using XML wouldn't have made any list of notable challenges on that project, for sure.
> However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing.
Oh wow, nice. IIRC I used Comet(?), which was my only big client-side dependency, to talk to a very simple bridge I wrote (probably Nodejs?) and OpenFire for the daemon, solely because it was stupid-easy to write a custom auth class (it's Java) so it could share accounts with our broader product without needing to modify any other parts of the system. Having some of that—at least the HTTP-bridge portion—already covered would have made it even easier.
18 comments
[ 2.6 ms ] story [ 49.2 ms ] threadAre Firefox's devtools actally worse then Chrome's though?
The chrome profiler is also incredibly slow, I suspect because the Chrome dev team rarely uses it and hasn't had to optimize it (they have a different profile viewer for things like tracing browser execution). The FF profiler is the main one the FF dev team uses, so in practice it's much faster. For that reason also it has profile sharing built in, which is handy.
The bit which is troublesome is account creation. Namely, it should be possible with a noscript/basic (x)html browser.
Now I wonder how they "filter" click farms (with humans or human trained mouse/keyboard AIs on blink/geeko/webkit) via swarms of compromised devices or via public VPNs.
A wild guess: post creation account behavior should give in enough hints at an account being "fake" or not. People with false positive won't be happy though.
https://github.com/taylordotfish/harmony/ https://github.com/taylordotfish/librecaptcha/ https://github.com/EionRobb/purple-discord/
Why should it though? Discord can’t be used without JavaScript.
For audio/video setup signaling then streaming, I wonder what are the simplest open protocols out there, but good enough to do the job.
I implemented a fair amount of XMPP for a web client back around 2012, and I gotta say, the XML wasn't a problem, at all. Actually the whole thing was a lot easier than comments about how awful XMPP is might lead one to expect—I know a lot of the complexity is in extensions, which I barely touched (but some!), but some people paint the whole protocol as unworkably bad, and that's simply not true.
As for the XML side of it in particular, XML compresses well, isn't slow to write by hand with modern editor features, and working with it in a browser is great because—and maybe this isn't common knowledge?—you can tell the browser to build a DOM out of XML, not just html, so you can let it handle parsing and constructing or modifying messages, meaning you can get pretty damn far implementing XMPP with surprisingly few lines of code and no external libs.
One thing that can be annoying is that some environments don't have streaming ("SAX") parsers readily available. That's less of a problem these days, but framing would have helped implementers in that regard. However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing.
Oh, sure, XML can be a nightmare, it was just good enough in XMPP's case that I doubt anything else would have been much easier/better. There were some minor annoyances and awkwardness, but that's hard to completely eliminate in that kind of thing. Its using XML wouldn't have made any list of notable challenges on that project, for sure.
> However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing.
Oh wow, nice. IIRC I used Comet(?), which was my only big client-side dependency, to talk to a very simple bridge I wrote (probably Nodejs?) and OpenFire for the daemon, solely because it was stupid-easy to write a custom auth class (it's Java) so it could share accounts with our broader product without needing to modify any other parts of the system. Having some of that—at least the HTTP-bridge portion—already covered would have made it even easier.
I wrote an XMPP bridge for it at: https://modules.prosody.im/mod_pubsub_eventsource
Of course if you need bidirectional (and not REST) then you generally need to upgrade to websockets.