Which in the case of the web to a large degree means "follow the consumer" (of web content, so including firms; and developers so close to consumers to be the same for this purpose).
There are clearly a lot of people that share this sentiment, and sometimes I sort of do too. Is there an answer for those who feel this way? A directory of sites that are pure html, no scripting (and maybe no styles)? a next-gen gopher? RSS? the library? Or maybe there isn't an answer?
If you want to read the web as nicely formatted text, using the same large, easy to read font for every site, it can be done. If you want to browse sites as lists and make selections from lists like you did on gopher, it can be done.
I have done a lot of work over the years on this for myself because this is how I prefer to retrieve, store and consume information. I have not run into many roadblocks. All that javascript and CSS really is optional.
I rarely use "modern" browsers for accessing the web. I do use them on private LAN's to access local files, but only because smartphones and tablets force you to use them.
On the web, I rewrite pages on the fly and view them with a text-only browser. Or I extract the bits I need from pages. In both cases usually I'm using a stream editor/filter, and sometimes a proxy if I'm modifying packets. Sometimes I put the results into csv or text files, kdb+, or cdb.
If I want to start using a "modern" browser I can do that any day at any time. The "modern" browser is always there if and when I need it. No learning curve. Beginners always welcome.
But to use the web effectively without using those graphical browsers could take practice for the uninitiated. I have practiced this for many years and it has become like second nature.
> But to use the web effectively without using those graphical browsers could take practice for the uninitiated. I have practiced this for many years and it has become like second nature.
Any tips? I would love to do this, both from my home computer and, all the more so, from my phone.
I've long used Linux, vim, and w3m for various sorts of tasks, some curl and wget as well. Wget is often blocked by sites unless it spoofs a more common browser agent.) I have similar preferences to you, though of late I'm largely using graphical browsers (Firefox by preference, for flexibility, Chrome unfortunately has better performance, though especially on Android, virtually zero configurability.
I've been thinking of scrapping much of this, un-rusting my emacs skills and doing something with:
* Emacs.
* Buffers.
* Built-in browser.
* Some local on-disk hierarchy essentially reflecting structure of websites I frequently access. Much of the information I access is actually pretty static, and there's a small subset of what I browse that's actually useful to keep.
* Extracting just the usful bits from each page. The primary text content and associated graphics, mostly. Dynamic and interactive components are rare, and there I'll likely hit up a graphical browser, treating it more as an applications environment.
* Metadata management. A standardised format of recording at least the site, publication date (if known), author (if known), access date, perceived quality, topic tags or categories (possibly a LoCCS hierarchy -- it's more sane than it seems), and a set of flags for issues (clickbait, bullshit, innacurracy, etc.) All this is shades of Vannevar Bush's Memex, though not a strict interpretation.
* A ratings and reputation system. What authors, sites, and publishers are or aren't generally credible or high-quality.
* If possible, a presentation mode that's more similar to Pocket than just a monospace text presentation, though that might also work.
* Annotations and notes.
* Bibliography generation.
Emacs strikes me as likely the perfet tool for much of this, with a bunch of built-in support already, from various modes, browsers, tools, Lisp, org-mode, etc.
Browsers became OSes because existing OSes have a poor security model and a very poor application delivery model. The browser offers an alternative way to ship an app to a user without having to go through the pain and suffering of building, testing, and packaging Windows, Linux, Mac, etc. applications for the end user.
We know because we do the latter and it hurts. Bad. Especially if you are targeting a wide customer base on multiple platforms. The pain.
Mobile OSes are somewhat better in this regard from a technical point of view, but in place of awful technology they have substituted the app store nightmare. I've dealt with both the Apple app store and the IRS, and the latter has far better customer service. This is partly because vendors wanted total control over the "next" platform, and partly because iOS and Android did not actually solve the security aspect of the OS application model. Instead they punted on the problem by deciding to just gate keep all code and to offer a reduced functionality profile to apps.
I am not entirely convinced browsers becoming OSes is a bad thing, and I half suspect that the web is actually an incubator for the next real innovation in the OS and platform space. The browser is at least prototyping an OS capable of rapidly loading and executing untrusted code without instantly melting down or being pwned by the first bit of malicious code that comes by. This is big. Try executing code this promiscuously with Windows, Linux, or Mac, or jail-broken Android or iOS for that matter.
The web became an OS because there's a huge demand for cross-platform zero-install software applications that run in a sandbox without dangerous user level access to your machine.
Given the context of the thread, it's remiss of you not to include some more context:
#1 OS X
#2 Linux
#5 iPhone OS
#6 Flash
#8 Debian Linux
#9 Windows XP
#10 Windows Server 2008
Which is to say that, except for Flash, all of the top 10 products are browsers or OSes.
On the other hand, looking at the full list, I'm not so sure I trust the data curation. The JRE and JDK are each listed twice (because Oracle bought out Sun), and Internet Explorer and IE are two separate listings.
There is also pain to test web apps for numerous browsers (so much fun on mobile)
in term of security, popular browsers are in the top 10 of most exploited software
so yeah the delivery model is nice, the update model too, but still I'm not convinced that the web model for apps is the "end all, be all" of app development
I could even argue that more and more apps are coming back to native, first instigated by the mobile app stores, which then expanded to the desktop app stores.
There is room for everyone, web apps and native apps, but still I would not want to use something like gmail as a browser app on my mobile.
I fear that the "instant" distribution and update via the net has resulted in sloppy programmers. This because they can always just push a fix by hitting a few keys.
That isn't _its_ feature. It belongs in a web browser as much as it belongs in Adobe Acrobat (although you could consider that a VM for executing untrusted code, too -- heoh!)
If you want a VM for executing untrusted code, use a VM for untrusted code, don't shoehorn it into HTML, or PDF, or whatever. That makes zero sense.
You appear to be conflating a relatively uncommon personal belief with the natural order of things. There is a small subset of people who believe electronic documents should be limited to what's possible with paper with the addition of links, but the vast majority of users and implementers want features which are only possible with interactivity. Once that's the case, you're talking untrusted code execution and it absolutely has to be integrated because much of the value comes from working with the document rather than just linking to a separate program.
PDF is a special case since there's similarly a considerable value in having things like forms, equations, graphs/illustrations, etc. being interactive but since Adobe has a stranglehold on the format, it was characteristically poorly designed, badly implemented, effectively unsupported, and you had to pay to use it. I would not draw conclusions from this other than avoiding Adobe-encumbered ideas.
The other side of this position is forgetting how important network effects are. People did try to implement purer alternatives but they were always hindered by the need to deploy them first. The low-friction web model is extremely popular with users and any question of replacements or alternatives needs to fit into the gradual upgrade model of the web unless you can get Microsoft and Apple to ship it in the OS.
I wouldn't consider this the end of Microsoft's dominance in the "desktop" market. What's actually happening is that the desktop market is shrinking, and being slowly replaced by smartphones and tablets as the casual computer.
I doubt it's going to go away entirely so long as Microsoft continues to sponsor schools with Microsoft Office coursework, but I have a hard time believing that every house is going to continue to need a desktop computer for much longer. My parents can get almost everything they need done on an iPad, and are somewhat annoyed when they stumble on the rare site that makes them walk into the Office and use their computer instead of finishing the task on the couch.
I'm not so sure. Tablets are personal, certainly, but Microsoft and Sun didn't care so much about the "truly personal" computing market (the market that in the 80s/90s would be translated as "game consoles and PDAs.") Instead, they were after the workstation market: they both wanted to be the platform that businesses wrote their line-of-business Intranet-facing CRUD apps in. Any PC-targeted uses for their platforms were just loss-leaders to win mind-share in the enterprise server+workstation market.
And that is why Microsoft went all out when Netscape started pushing the intranet idea, because it targeted the platform that MS had built up after they blindsided Novell.
Well, we're definitely at the point where my Web Browser uses more memory than my Operating System. I'm impressed, a great deal of this talk could be applied to modern browsers with a surprising degree of accuracy.
I love looking at the feature list and seeing what actually caught on (Audio Playback) and the laundry list of features that seemed like good ideas at the time, but had no place in the browser. CoolTalk eventually got implemented as VOIP, and chat features showed up on websites once JavaScript got good enough to facilitate it, but nearly everything else has fallen by the wayside.
Linux is the kernel. The semantics of this can be argued all day, but the kernel is not the operating system. It is simply the tiny piece of software that allows processes to run and manages memory and hardware access. The operating system is the whole collection of software that allows the User to manage their system. It necessarily includes the kernel, but it is much more than just that one component.
I don't consider ChromeOS to be a Linux desktop any more than I consider my Android smartphone to be a Linux desktop, or an iPhone to be a BSD system. They happen to share a kernel, but that's really where the similarities end as an end user.
On my p133 with 32MB of RAM (running mandrake linux, Enlighenment DR0.15 CVS built weekly), Mozilla milestones would constantly swap out to disk while running, due to the massive RAM requirements.
My current KDE Plasma 5 system (Calculate Linux) uses about 300MB idle. Firefox (Same gecko core) is using 464MB of RAM right now with 7 tabs open.
I'm currently building servo (with browser.html) for the first time, and I expect similar RAM requirements.
VRML was way ahead of its time. In the bad way, where the technology totally sucks on the machines of the era and people think it's a joke for years afterward. I've been wondering how long it takes till someone reinvents it now that VR goggles are finally starting to become affordable and broadband is common.
I don't remember Cooltalk at all. Did it never make it past the Alpha? Did it only ship on Windows? The blurb makes it sound fairly interesting. A built-in IRC client (or maybe ICQ?), VoIP, and a shared whiteboard facility. It really imagines the browser as part of a bidirectional communication system not just a viewer for published content.
Knowing the timeframe it probably didn't work through NAT and died as static IPs for residential customers stopped being a thing. NAT broke a lot of promising applications back in the day.
If Cooltalk is the same thing I'm thinking about, it took about five minutes to start and absolutely crushed the average PC. Netscape dropped it after a couple point releases. It was Java-based but might have been Windows-only.
On the contrary. Ideally you'd be using 80-90% of your RAM at all times. Ever notice that the more RAM you have, the more your computer uses? Unused RAM is wasted RAM. Recent versions of Windows for example cache things into RAM to speed up the loading of frequently accessed applications. If you run low on RAM, then it frees up room as needed.
I don't think the parent comment/thread was correctly read. The point is that an ideal OS would consume no resources leaving them entirely for the applications to use. The OS caching frequently used applications is different from the OS itself needing resources.
What's strange about that? Applications should be using a computer's resources. That's like declaring that employees now get more of a company's payroll than management.
So, Netscape Atlas was 6 megabytes in June 1996; Firefox for Windows 64-bit is 45.2 megabytes today (I picked the Windows download because it sounds like this guy was using Windows back then); that means the size has multiplied by 7.5 over the last twenty years, for an annual increase of about 10½%. That's — not terribly great, actually.
OTOH, according to http://www.jcmit.com/diskprice.htm disk prices have been dropping by almost a third every year, with the result that the cost of a Firefox install in 2016 is less than 1/500th the cost of a Netscape install in 1996. That's pretty awesome!
How much of that is purely graphical and other resources though? Like the hi res image on the opening page, all the icons, translations etc.
I saw someone do a similar analysis recently about how bloated vim had become but it was mostly documentation (plus translations) and stuff like that, not vim itself.
Even graphical resources are probably not stored as optimally as they could be, given what the demoscene can do in a 4 kilobyte binary... one of my pet peeves is gradients, simple shapes, or even completely flat regions of colour(!) stored as bitmaps. I've seen apps with multiple sizes of the same simple --- as in completely linear --- gradient stored as uncompressed bitmaps.
I some someone do a similar thing about how bloated vim had become but it was mostly documentation (plus translations) and stuff like that, not vim itself.
Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"
That also reminds me of a few programs I've come across that inexplicably let you dynamically change their UI language to one of around a dozen choices (and all the language names were in English too...) If I remember correctly, it was something simple like a file converter or downloader where most of the UI was icons anyway, and around 90% of the installer package's size was these resource files. Just... why.
> I've seen apps with multiple sizes of the same simple --- as in completely linear --- gradient stored as uncompressed bitmaps.
Android required this at one point for different resolutions. I'd be surprised if the svg proccessing used more time and battery (not to mention space) than loading uncompressed images from disk.
> Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"
I guess that's down to the limitations of various app stores/package managers. All the windows deployment options are awful enough that that I'd bundle everything too. I'm not aware of app stores that allow dependencies or optional packages. Billions of dollars flow through these stores but they're still more limited than apt.
Packages managers (apt, chocolaty, etc) can do it but would still need a few tweaks to do it well.
At least in pacman, you have to download the entire archive (because the packager's GPG signature goes over the full archive file), but you can set the NoExtract option e.g. to avoid the translations from being extracted: https://github.com/majewsky/system-configuration/blob/master...
Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"
Because packagers don't have the patience to split them up. LibreOffice on Debian & derivatives, for example, has a different package for each localization plus a different package for the Help files in each language.
I would like to think that after 20 years of effort, Netscape actually does more than 7.5 times as much stuff as it did in 1996. Assuming the original version even runs anymore, you should fire it up and see how it compares to a modern web browser.
I would assume that most of the logic for what Netscape did was embedded in the Netscape binary, while most modern browser features are 1% browser binary code, and 99% calls into the huge iceberg of OS-provided libraries.
Compare, for example, how VRML worked (entirely software rendering, all the code inside the browser) to how WebGL works (an API to talk to the OS graphics driver, which in turn is just a very fat API on top of the very CISC instruction set of a GPU.)
Why do you say that the GPU has a "very CISC instruction set"? The RISC/CISC divide is a somewhat historical notion, and GPUs don't really seem to fall in either camp to me (separate load/store + tons of GPRs + VLIW = RISC-like, transcendental functions + texture fetch with interpolation = CISC-like).
I was taking a bit of poetic license there; what I meant is that the ABI that the GPU presents to the CPU contains a number of high-level instructions that must be further decoded within the GPU, in the same way that modern "CISC-presenting" processors decode CISC ops into RISC μops.
That's only for graphics programming, mind you; the GPGPU interface is pretty directly representative of the GPU's internal RISC execution strategy.
Not true. To keep things compatible and minimize platform bugs, browsers embed a lot. Firefox has it's own jpeg, png, video codec and spelling libraries built-in. Try compiling it sometime. It takes forever.
Absolutely fascinating site, thanks! I felt incredibly nostalgic loading Netscape on Mac OS and using those squidgy grey menus. Wow do I suddenly feel old and miss those old simple machines (the OS version is 7.5.5).
'The next generation of mobile phones will make it much easier for the police to carry out covert surveillance of citizens, say civil liberty campaigners.'
The last time i tested old browsers it was impossible to view anything. The main problem is the Host field isn't sent by a lot of browsers from that time, and sites won't respond.
Character encoding issues, nexpected tags, big images all quickly lead to crashes.
>I would like to think that after 20 years of effort, Netscape actually does more than 7.5 times as much stuff as it did in 1996.
This is precisely the problem the article is about. Why should one application grow 7.5 responsibilities instead of those being in separate applications? It's simply poor design, and now we're stuck with it.
To some extent, the 7.5 times (stuck with this arbitrary figure now …) more things that it does are not necessarily externalisable bloat—it hasn't grown an e-mail client (I think?)—but rather a response to the increasing demands of modern web pages. Offloading, say, JavaScript processing (a not-insignificant part of modern browser code, I think) to a separate application is surely possible, but also surely pointless.
> I would like to think that after 20 years of effort, Netscape actually does more than 7.5 times as much stuff as it did in 1996.
Does it though? In 1996 it included a mail client, a news client and a gopher client along with its HTTP & FTP clients. It even had JavaScript back then (I'm just going to take a moment to lament that JavaScript could have been Scheme — I don't even like Scheme as a language for programs, but as a language for web pages and web apps it would have been plenty good enough, even excellent!). It displayed images; it displayed HTML.
Honestly, 1996 was a pretty good year for browsers.
It really seems like it makes sense that browsers really "need" the bloat; it has got to the point where it ends up being the most useful and most used application on any OS, for a given section of the end-user base, anyway.
At that point can we really call those features bloat? Maybe in 1996 you didn't need to play videos much, but a web browser without HTML 5 can't do what the majority would expect. What users expect from the internet has very much expanded.
I actually was curious about some of the inner workings of this stuff and made a browser using WebKit once.
> It really seems like it makes sense that browsers really "need" the bloat; it has got to the point where it ends up being the most useful and most used application on any OS, for a given section of the end-user base, anyway.
Effectively the browser has in the GUI age become what the terminal emulator was in the CLI age.
On its own the browser do jack all. But it allows remote resources to present a local UI.
Thus my lowly desktop PC can become a virtual supercomputer.
and yet 20 years later, the situation is not that better ...
each browser vendors is still fighting the other ones by adding features that make their browser the platform of choice like chrome API only available for the chrome app store
let's all kill Flash because plugins are bad, but let's not hesitate to add our own plugin, oh excuse me the politically correct word is "addon" as a native extension to cast things around.
when CPU, RAM and bandwidth are no more an issues let's cache aggressively everything so that bloated browser does not feel so slow anymore.
Modern browser extensions are written in JavaScript, making them portable, verifiable, and easily sandboxed - not something you get with an executable binary blob that until very recently ran in the same permission context as the local user - which on Win9x through XP meant root.
Handily (and amusingly), Microsoft's Edge extension API is designed to be compatible with Chrome's - I understand there's a degree of mutual-intelligibility with Firefix too.
And aggressive caching just makes sense - consider people today with 10+ Chrome Windows open, all with 50+ tabs each - not even 10 years ago IE6 still ruled supreme - with one document per window. And even then machines had similar orders-of-magnitude of RAM as they do today - my 2006 rig had 4GB of RAM (XPx64) my current machine has 4 times that.
> Modern browser extensions are written in JavaScript, making them portable, verifiable, and easily sandboxed - not something you get with an executable binary blob that until very recently ran in the same permission context as the local user - which on Win9x through XP meant root.
Do you think this means that browser extensions are secure in the least?
84 comments
[ 3.0 ms ] story [ 152 ms ] threadI rarely use "modern" browsers for accessing the web. I do use them on private LAN's to access local files, but only because smartphones and tablets force you to use them.
On the web, I rewrite pages on the fly and view them with a text-only browser. Or I extract the bits I need from pages. In both cases usually I'm using a stream editor/filter, and sometimes a proxy if I'm modifying packets. Sometimes I put the results into csv or text files, kdb+, or cdb.
If I want to start using a "modern" browser I can do that any day at any time. The "modern" browser is always there if and when I need it. No learning curve. Beginners always welcome.
But to use the web effectively without using those graphical browsers could take practice for the uninitiated. I have practiced this for many years and it has become like second nature.
Any tips? I would love to do this, both from my home computer and, all the more so, from my phone.
I've long used Linux, vim, and w3m for various sorts of tasks, some curl and wget as well. Wget is often blocked by sites unless it spoofs a more common browser agent.) I have similar preferences to you, though of late I'm largely using graphical browsers (Firefox by preference, for flexibility, Chrome unfortunately has better performance, though especially on Android, virtually zero configurability.
I've been thinking of scrapping much of this, un-rusting my emacs skills and doing something with:
* Emacs.
* Buffers.
* Built-in browser.
* Some local on-disk hierarchy essentially reflecting structure of websites I frequently access. Much of the information I access is actually pretty static, and there's a small subset of what I browse that's actually useful to keep.
* Extracting just the usful bits from each page. The primary text content and associated graphics, mostly. Dynamic and interactive components are rare, and there I'll likely hit up a graphical browser, treating it more as an applications environment.
* Metadata management. A standardised format of recording at least the site, publication date (if known), author (if known), access date, perceived quality, topic tags or categories (possibly a LoCCS hierarchy -- it's more sane than it seems), and a set of flags for issues (clickbait, bullshit, innacurracy, etc.) All this is shades of Vannevar Bush's Memex, though not a strict interpretation.
* A ratings and reputation system. What authors, sites, and publishers are or aren't generally credible or high-quality.
* Integrated management of multiple document formats: HTML, PDF, ePub, DJVU, Mobi, text, Markdown.
* If possible, a presentation mode that's more similar to Pocket than just a monospace text presentation, though that might also work.
* Annotations and notes.
* Bibliography generation.
Emacs strikes me as likely the perfet tool for much of this, with a bunch of built-in support already, from various modes, browsers, tools, Lisp, org-mode, etc.
Just rambling....
Think of how many businesses, groups, etc no longer have websites. They might have a meetup page, but they most definitely have a Facebook Page.
If they have a website, it often embeds their Facebook event listing or uses some Wordpress/Drupal plugin to sync it for them.
The Internet is more centralized and less distributed than it was in the 1990s.
We know because we do the latter and it hurts. Bad. Especially if you are targeting a wide customer base on multiple platforms. The pain.
Mobile OSes are somewhat better in this regard from a technical point of view, but in place of awful technology they have substituted the app store nightmare. I've dealt with both the Apple app store and the IRS, and the latter has far better customer service. This is partly because vendors wanted total control over the "next" platform, and partly because iOS and Android did not actually solve the security aspect of the OS application model. Instead they punted on the problem by deciding to just gate keep all code and to offer a reduced functionality profile to apps.
I am not entirely convinced browsers becoming OSes is a bad thing, and I half suspect that the web is actually an incubator for the next real innovation in the OS and platform space. The browser is at least prototyping an OS capable of rapidly loading and executing untrusted code without instantly melting down or being pwned by the first bit of malicious code that comes by. This is big. Try executing code this promiscuously with Windows, Linux, or Mac, or jail-broken Android or iOS for that matter.
The web became an OS because there's a huge demand for cross-platform zero-install software applications that run in a sandbox without dangerous user level access to your machine.
Top 50 Products By Total Number Of "Distinct" Vulnerabilities http://www.cvedetails.com/top-50-products.php
#3 Firefox
#4 Chrome
#7 Internet Explorer
#1 OS X
#2 Linux
#5 iPhone OS
#6 Flash
#8 Debian Linux
#9 Windows XP
#10 Windows Server 2008
Which is to say that, except for Flash, all of the top 10 products are browsers or OSes.
On the other hand, looking at the full list, I'm not so sure I trust the data curation. The JRE and JDK are each listed twice (because Oracle bought out Sun), and Internet Explorer and IE are two separate listings.
in term of security, popular browsers are in the top 10 of most exploited software
so yeah the delivery model is nice, the update model too, but still I'm not convinced that the web model for apps is the "end all, be all" of app development
I could even argue that more and more apps are coming back to native, first instigated by the mobile app stores, which then expanded to the desktop app stores.
There is room for everyone, web apps and native apps, but still I would not want to use something like gmail as a browser app on my mobile.
If you want a VM for executing untrusted code, use a VM for untrusted code, don't shoehorn it into HTML, or PDF, or whatever. That makes zero sense.
PDF is a special case since there's similarly a considerable value in having things like forms, equations, graphs/illustrations, etc. being interactive but since Adobe has a stranglehold on the format, it was characteristically poorly designed, badly implemented, effectively unsupported, and you had to pay to use it. I would not draw conclusions from this other than avoiding Adobe-encumbered ideas.
The other side of this position is forgetting how important network effects are. People did try to implement purer alternatives but they were always hindered by the need to deploy them first. The low-friction web model is extremely popular with users and any question of replacements or alternatives needs to fit into the gradual upgrade model of the web unless you can get Microsoft and Apple to ship it in the OS.
Android apps are written in Java. There's still time...
I doubt it's going to go away entirely so long as Microsoft continues to sponsor schools with Microsoft Office coursework, but I have a hard time believing that every house is going to continue to need a desktop computer for much longer. My parents can get almost everything they need done on an iPad, and are somewhat annoyed when they stumble on the rare site that makes them walk into the Office and use their computer instead of finishing the task on the couch.
I love looking at the feature list and seeing what actually caught on (Audio Playback) and the laundry list of features that seemed like good ideas at the time, but had no place in the browser. CoolTalk eventually got implemented as VOIP, and chat features showed up on websites once JavaScript got good enough to facilitate it, but nearly everything else has fallen by the wayside.
I don't consider ChromeOS to be a Linux desktop any more than I consider my Android smartphone to be a Linux desktop, or an iPhone to be a BSD system. They happen to share a kernel, but that's really where the similarities end as an end user.
On my p133 with 32MB of RAM (running mandrake linux, Enlighenment DR0.15 CVS built weekly), Mozilla milestones would constantly swap out to disk while running, due to the massive RAM requirements.
My current KDE Plasma 5 system (Calculate Linux) uses about 300MB idle. Firefox (Same gecko core) is using 464MB of RAM right now with 7 tabs open.
I'm currently building servo (with browser.html) for the first time, and I expect similar RAM requirements.
I still remember trying to find all the VRML sites I could find, in all of it's few polygon glory.
Initiated by the developer who started WebGL.
Knowing the timeframe it probably didn't work through NAT and died as static IPs for residential customers stopped being a thing. NAT broke a lot of promising applications back in the day.
Done! And of course, many apps routinely now take more memory than the OS.
WikiPedia (https://en.wikipedia.org/wiki/Microsoft_FrontPage) says that it was 1.1 in 1996 and 2 in 1997 (also called FrontPage 98).
This might not be an original unmodified-since-1996 page.
Beautiful page though.
https://web.archive.org/web/19970226231531/http://www.miken....
The GENERATOR tag was added in 2001-2002:
https://web.archive.org/web/20020624063420/http://miken.com/...
OTOH, according to http://www.jcmit.com/diskprice.htm disk prices have been dropping by almost a third every year, with the result that the cost of a Firefox install in 2016 is less than 1/500th the cost of a Netscape install in 1996. That's pretty awesome!
[1] https://productforums.google.com/forum/#!topic/chrome/KRGYQb...
I saw someone do a similar analysis recently about how bloated vim had become but it was mostly documentation (plus translations) and stuff like that, not vim itself.
I some someone do a similar thing about how bloated vim had become but it was mostly documentation (plus translations) and stuff like that, not vim itself.
Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"
That also reminds me of a few programs I've come across that inexplicably let you dynamically change their UI language to one of around a dozen choices (and all the language names were in English too...) If I remember correctly, it was something simple like a file converter or downloader where most of the UI was icons anyway, and around 90% of the installer package's size was these resource files. Just... why.
Android required this at one point for different resolutions. I'd be surprised if the svg proccessing used more time and battery (not to mention space) than loading uncompressed images from disk.
> Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"
I guess that's down to the limitations of various app stores/package managers. All the windows deployment options are awful enough that that I'd bundle everything too. I'm not aware of app stores that allow dependencies or optional packages. Billions of dollars flow through these stores but they're still more limited than apt.
Packages managers (apt, chocolaty, etc) can do it but would still need a few tweaks to do it well.
Because packagers don't have the patience to split them up. LibreOffice on Debian & derivatives, for example, has a different package for each localization plus a different package for the Help files in each language.
Compare, for example, how VRML worked (entirely software rendering, all the code inside the browser) to how WebGL works (an API to talk to the OS graphics driver, which in turn is just a very fat API on top of the very CISC instruction set of a GPU.)
That's only for graphics programming, mind you; the GPGPU interface is pretty directly representative of the GPU's internal RISC execution strategy.
It doesn't do too well: http://oldweb.today/
Found this alarmingly prescient piece on the BBC site from 2000:
http://news.bbc.co.uk/1/hi/sci/tech/874419.stm
'The next generation of mobile phones will make it much easier for the police to carry out covert surveillance of citizens, say civil liberty campaigners.'
Hmm, I wonder how that will play out...
Character encoding issues, nexpected tags, big images all quickly lead to crashes.
This is precisely the problem the article is about. Why should one application grow 7.5 responsibilities instead of those being in separate applications? It's simply poor design, and now we're stuck with it.
Does it though? In 1996 it included a mail client, a news client and a gopher client along with its HTTP & FTP clients. It even had JavaScript back then (I'm just going to take a moment to lament that JavaScript could have been Scheme — I don't even like Scheme as a language for programs, but as a language for web pages and web apps it would have been plenty good enough, even excellent!). It displayed images; it displayed HTML.
Honestly, 1996 was a pretty good year for browsers.
It really seems like it makes sense that browsers really "need" the bloat; it has got to the point where it ends up being the most useful and most used application on any OS, for a given section of the end-user base, anyway.
At that point can we really call those features bloat? Maybe in 1996 you didn't need to play videos much, but a web browser without HTML 5 can't do what the majority would expect. What users expect from the internet has very much expanded.
I actually was curious about some of the inner workings of this stuff and made a browser using WebKit once.
https://gitlab.com/ibiscybernetics/sighte
All-in-all one of the more unusual side projects I played with.
Effectively the browser has in the GUI age become what the terminal emulator was in the CLI age.
On its own the browser do jack all. But it allows remote resources to present a local UI.
Thus my lowly desktop PC can become a virtual supercomputer.
each browser vendors is still fighting the other ones by adding features that make their browser the platform of choice like chrome API only available for the chrome app store
let's all kill Flash because plugins are bad, but let's not hesitate to add our own plugin, oh excuse me the politically correct word is "addon" as a native extension to cast things around.
when CPU, RAM and bandwidth are no more an issues let's cache aggressively everything so that bloated browser does not feel so slow anymore.
Google cast is built into chrome https://news.ycombinator.com/item?id=12383367
Handily (and amusingly), Microsoft's Edge extension API is designed to be compatible with Chrome's - I understand there's a degree of mutual-intelligibility with Firefix too.
And aggressive caching just makes sense - consider people today with 10+ Chrome Windows open, all with 50+ tabs each - not even 10 years ago IE6 still ruled supreme - with one document per window. And even then machines had similar orders-of-magnitude of RAM as they do today - my 2006 rig had 4GB of RAM (XPx64) my current machine has 4 times that.
Do you think this means that browser extensions are secure in the least?
HN is like 9 kb.