4 ms·

My question to everyone is: What is the reason for a _browser_ to have an integrated _chat client_? In my opinion, it doesn't make any sense. We should keep s

My question to everyone is: What is the reason for a _browser_ to have an integrated _chat client_? In my opinion, it doesn't make any sense. We should keep separated tools that do different jobs, and make each one general enough that it can be used in every situation.

gpvos 10y ago
I used to agree, but even I now sometimes use the camera of my phone.
- kwanbis 10y ago
  That is a totally different need. You carry one gadget instead of two, and the camera gets benefits from the connectivity of the phone.
- SlySherZ 10y ago
  That's a very good point, some things are very good at doing everything. But I don't think that should apply to the browser. Firefox already gives you extensions, which means you can add to it whatever you need. Would you say the browser should come with a painter program by default? Maybe a file manager too? What about a specific program to print for a specific printer? At what point should you stop reinventing the wheel?
- adrusi 10y ago
  There's an important difference between hardware and software. Hardware takes up space. It would probably be better to have a dedicated DSLR and a dedicated radio communication device that have a standard method of interoperability, if not for the fact that you'd have to carry them both around. You'd have better quality photos, and could take both wide-angle and zoomed shots, and you could swap out your camera to suit your needs, instead of always having the one camera soldered onto your phone. Software takes up no space.
  - gpvos 10y ago
    I agree and understand; I was being a bit facetious there. However, I actually still don't quite understand why browsers can play video and audio. I much rather play those in dedicated software, to the extent that I regularly view the source of such pages to figure out the URL of the media to be played. I guess this is because of ease of use for the average user, and occasionally for DRM, but it annoys me to no end. Playing all video or audio in the same software means a much better and consistent user interface for things like rewind, pause, full screen, etc.
    - adrusi 10y ago
      Definitely agree. If you want a remedy for the specific problem of audio and video, you could come up with some browser + youtube-dl integration. I've been using such a setup for the past year, watching web audio and video in mpv. It's great to have a consistent video player interface, as you said, but you also get powerful features you don't often see in web players, like gamma adjustment, playback speed control and an audio compressor.
Touche 10y ago
This was to promote WebRTC.
detaro 10y ago
I'm not convinced Hello should be in Firefox myself, but: One of the newer features of Hello is tab sharing, which is niche but clever, and needs some sort of browser integration. People use their browser (through webapps) for chat, mail, etc anyways, instead of using dedicated applications, so there doesn't seem to be much purity in that regard. And Hello is mostly build on web-tech the browser already has to support. Putting it there makes it more likely for people to quickly try it, and learn that browsers now can do cool new things with WebRTC.
sebhack 10y ago
Agreed. Integrating non-browser parts into a browser reminds me of the SeaMonkey days, where the browser wasn't just a browser but a whole "internet suite" with integrated email, IRC client, HTML editor... Glad these days are over.
bluejekyll 10y ago
What I really want to see is with webassembly the browser become the default rendering engine for all client side applications. We're already moving in that direction with things like electron. The browser should be a rendering engine, which is a pure sandbox, for client side applications. The client side applications will have access to standard local dbs, standard Dom and CSS renderers and standard method of running code through webassembly. Webassembly with DOM access is IMO the final piece to do this. And then all OS device access will be done through this sandbox environment where there can be highly controlled access to things like mounted disks, etc. In this utopian future, all developers will be able to target any browser/OS with identical code and never have compatability issues. (And a choir of angels sing out in joy)
- super_mario 10y ago
  Why? What is the advantage of abstracting everything from the raw CPU so much and now treating JavaScript as CPU op codes? And wasn't that computing model all the range 40 years ago, with "big iron" (less powerful than my phone now) mainframes that lived far away and dumb terminals (essentially a keyboard and a screen with very little processing happening locally)? Are we saying computing is so hard that people can't be trusted with a real computer? Everything needs to be on someone else's computer and you are only allowed to have a locked down browser locally? I don't get this everything old is new again trend. And how enthusiastic today's kids are about their grandfather's computing model.
  - pcwalton 10y ago
    > Why? What is the advantage of abstracting everything from the raw CPU so much Portability (and not just between architectures--between operating systems as well). > and now treating JavaScript as CPU op codes? Web Assembly does not treat JavaScript as "CPU op codes".
  - bluejekyll 10y ago
    Pcwalton's response is good. I'll add that I think your confused about what I am saying. In the JavaScript world, the single page app is really just a pure client side app, no different than an app dedicated to Windows like Word. The difference is that it targets web standards for building applications, in a sense the browser is the operating system and application development environment that the OS used to provide. The key is that it's a standard, and should work the same across platforms. The fact that it's on the web is just a delivery platform for the software. Webassembly will bring the performance of these browser based applications to be on par with any native application. It's the write once run everywhere development that we've all wanted since the promise that Java made. I do think that there is a benefit to this model over Java, which is that it's more flexible than Java was in allowing for design choice, and many more languages (in large part thanks to the LLVM).
l0b0 10y ago
History repeats itself - bloat was the main driver for forking Mozilla Application Suite 14 years ago, IIRC not very long after MAS included a chat client.
ivcha 10y ago
Regular chat capabilities + easy sharing of current browser views, of course. I use it regularly, e.g. when deciding to buy a ticket with my friends.

gpvos 10y ago

I used to agree, but even I now sometimes use the camera of my phone.

kwanbis 10y ago
That is a totally different need. You carry one gadget instead of two, and the camera gets benefits from the connectivity of the phone.
SlySherZ 10y ago
That's a very good point, some things are very good at doing everything. But I don't think that should apply to the browser. Firefox already gives you extensions, which means you can add to it whatever you need. Would you say the browser should come with a painter program by default? Maybe a file manager too? What about a specific program to print for a specific printer? At what point should you stop reinventing the wheel?
adrusi 10y ago
There's an important difference between hardware and software. Hardware takes up space. It would probably be better to have a dedicated DSLR and a dedicated radio communication device that have a standard method of interoperability, if not for the fact that you'd have to carry them both around. You'd have better quality photos, and could take both wide-angle and zoomed shots, and you could swap out your camera to suit your needs, instead of always having the one camera soldered onto your phone. Software takes up no space.
- gpvos 10y ago
  I agree and understand; I was being a bit facetious there. However, I actually still don't quite understand why browsers can play video and audio. I much rather play those in dedicated software, to the extent that I regularly view the source of such pages to figure out the URL of the media to be played. I guess this is because of ease of use for the average user, and occasionally for DRM, but it annoys me to no end. Playing all video or audio in the same software means a much better and consistent user interface for things like rewind, pause, full screen, etc.
  - adrusi 10y ago
    Definitely agree. If you want a remedy for the specific problem of audio and video, you could come up with some browser + youtube-dl integration. I've been using such a setup for the past year, watching web audio and video in mpv. It's great to have a consistent video player interface, as you said, but you also get powerful features you don't often see in web players, like gamma adjustment, playback speed control and an audio compressor.

Touche 10y ago

This was to promote WebRTC.

detaro 10y ago

I'm not convinced Hello should be in Firefox myself, but: One of the newer features of Hello is tab sharing, which is niche but clever, and needs some sort of browser integration. People use their browser (through webapps) for chat, mail, etc anyways, instead of using dedicated applications, so there doesn't seem to be much purity in that regard. And Hello is mostly build on web-tech the browser already has to support. Putting it there makes it more likely for people to quickly try it, and learn that browsers now can do cool new things with WebRTC.

sebhack 10y ago

Agreed. Integrating non-browser parts into a browser reminds me of the SeaMonkey days, where the browser wasn't just a browser but a whole "internet suite" with integrated email, IRC client, HTML editor... Glad these days are over.

bluejekyll 10y ago

What I really want to see is with webassembly the browser become the default rendering engine for all client side applications. We're already moving in that direction with things like electron. The browser should be a rendering engine, which is a pure sandbox, for client side applications. The client side applications will have access to standard local dbs, standard Dom and CSS renderers and standard method of running code through webassembly. Webassembly with DOM access is IMO the final piece to do this. And then all OS device access will be done through this sandbox environment where there can be highly controlled access to things like mounted disks, etc. In this utopian future, all developers will be able to target any browser/OS with identical code and never have compatability issues. (And a choir of angels sing out in joy)

super_mario 10y ago
Why? What is the advantage of abstracting everything from the raw CPU so much and now treating JavaScript as CPU op codes? And wasn't that computing model all the range 40 years ago, with "big iron" (less powerful than my phone now) mainframes that lived far away and dumb terminals (essentially a keyboard and a screen with very little processing happening locally)? Are we saying computing is so hard that people can't be trusted with a real computer? Everything needs to be on someone else's computer and you are only allowed to have a locked down browser locally? I don't get this everything old is new again trend. And how enthusiastic today's kids are about their grandfather's computing model.
- pcwalton 10y ago
  > Why? What is the advantage of abstracting everything from the raw CPU so much Portability (and not just between architectures--between operating systems as well). > and now treating JavaScript as CPU op codes? Web Assembly does not treat JavaScript as "CPU op codes".
- bluejekyll 10y ago
  Pcwalton's response is good. I'll add that I think your confused about what I am saying. In the JavaScript world, the single page app is really just a pure client side app, no different than an app dedicated to Windows like Word. The difference is that it targets web standards for building applications, in a sense the browser is the operating system and application development environment that the OS used to provide. The key is that it's a standard, and should work the same across platforms. The fact that it's on the web is just a delivery platform for the software. Webassembly will bring the performance of these browser based applications to be on par with any native application. It's the write once run everywhere development that we've all wanted since the promise that Java made. I do think that there is a benefit to this model over Java, which is that it's more flexible than Java was in allowing for design choice, and many more languages (in large part thanks to the LLVM).

l0b0 10y ago

History repeats itself - bloat was the main driver for forking Mozilla Application Suite 14 years ago, IIRC not very long after MAS included a chat client.

ivcha 10y ago

Regular chat capabilities + easy sharing of current browser views, of course. I use it regularly, e.g. when deciding to buy a ticket with my friends.