The end of the web browser

IMHO at the time of early web (near 2000) the plans were to use HTML for static hypertext pages and simple feedback (e.g. registration forms). For rich GUI people expected to use Java or similar language. Click link, browser loads and starts java executable. But security was in doubt. In addition Java was developed by Sun and browsers by other companies. And last but not least Java was very slow for computers at that time. “Knock, knock. Who’s there? (very long pause…) Java.”

Java applets also failed to morph with the browser's window geometry. Just a dumb rectangle.
 
IMHO at the time of early web (near 2000) the plans were to use HTML for static hypertext pages and simple feedback (e.g. registration forms). For rich GUI people expected to use Java or similar language. Click link, browser loads and starts java executable. But security was in doubt. In addition Java was developed by Sun and browsers by other companies. And last but not least Java was very slow for computers at that time. “Knock, knock. Who’s there? (very long pause…) Java.”
Precisely. This is why Flash became such a big thing, because it loaded quick enough, did a lot of things HTML could not and was also vector based. Well it was a thing until Steve Jobs killed it in 2011.
 
The best one was "vanced" ("ADvanced, but without ADs) which was basically the reverse-engineered youtube client, but whilst it's claimed the app still works fine, that project is dead after a cease-and-desist from google. You could google it for "research purposes"
If Google bothers to send a cease-and-desist letter, that's a good sign that it works. 😁
 
Okay, so I've just "browsed" through this thread for the 3rd or 4th time, but I still fail to understand exactly what it is that's supposed to replace web browsers? Are we saying here that a "phone browser" is not the same thing as a "web browser," when it's mainly only the content delivery device and its size that's changed? Isn't it still so, to misquote the bard, that a rose by any other name will still give you hay fever?

It's understandable that a thread like this might meander all over the place and hit on a lot of interesting sub-topics. Living in a backwater where the electricity has been known to go out for as long as 3 weeks at a time, I might have a little more appreciation for things like paper checks and books. Being entirely dependent on the scotch-tape-and-bailing-wire infrastructure of the internet, and on other people continuing to deliver our electricity to us, is problematic at best. Should I live to see the day when solar storms knock out the internet, or an asteroid strike wipes out the electric power grid, those of us who've held onto our books and non-electronic forms of communication will be in far better shape than we would've been otherwise.
 
Are we saying here that a "phone browser" is not the same thing as a "web browser," when it's mainly only the content delivery device and its size that's changed?
Comments for phone vs desktop browser are related to web page design. To read web page on phone, it has to have large font. The same design on 24-27" desktop display looks very bad with very big text. But designer thinks "Probably the user will see this on phone - the font size is OK. I have no time (do not want) to make 2 different versions of the same page - one for desktop and other for phone screen."
 
Okay, so I've just "browsed" through this thread for the 3rd or 4th time, but I still fail to understand exactly what it is that's supposed to replace web browsers? Are we saying here that a "phone browser" is not the same thing as a "web browser," when it's mainly only the content delivery device and its size that's changed? Isn't it still so, to misquote the bard, that a rose by any other name will still give you hay fever?
I thought that the point of this thread was to separate data from display. Take, for example, the weather forecast - the data may come from largely the same source, but may look very different depending on how it's delivered/received on the device. A phone browser is not the same thing as a desktop browser. Similar in functionality, but not the same thing. On a phone, you have the option to use a default weather app supplied by the phone manufacturer or a browser bookmark.

A native phone app will only request the data, receive it over HTTPS, and then use the phone's processing power to display it nicely. A browser has to also download the code to display the data, and phone browsers are generally designed to avoid that to the extent practical.
 
Yes, that is the alternative: different phone apps for everything. They can do it in the web, but they offer a wonderful, special phone app for their special service. You must install a lot of wonderfull (bloated) apps.

This "developement" is not new. The were wonderfull forum software (usenet), now there is different forum software for different forums that run on the web.
 
I am using now a Samsung nc10, Intel n270 cpu with OpenBSD 7.2. Firefox is not anymore in the packages. All graphical Browsers seg faults, have strange behaviour, are slow or have problems retrieving Web-sites, including chrome. It is a headache. With FreeBSD 12 we have similar problems, firefox is there, but not chrome. And firefox is not enough for every Web-Site. It seems, Web Sites are "optimized" for the last version of android with a smartphone not older that 1 year. Everything is getting difficult with a normal PC with a normal browser. The future is the smartphone.
Despite the fact that all browsers work fine for me on 13.1, I understand the complaints of the topicstarter. My purist solution to this problem:

1 - build a working computer using server hardware. If the processor - then I use only Xeon / Epyc / Opteron, etc. If memory - only ECC (useful for ZFS). If an array of disks - then only SAS or NVME (preferably for a server, not a consumer class). None of this is necessarily new, of course: it could be a modern Supermicro board or a 10-year-old IBM server. Look, we are given the ability to boot from a RAID-Z3 array, how can we not use it with SAS and ECC drives? At the very least, if you have reliable hardware, and then you catch problems with the operating system, then you can cross out the hardware from the list of suspects.

2 - it is obvious that the above hardware is necessary for serious tasks: programming, compiling programs, storing important data. It won't have a sound card - no problem, no need to mess up a hi-end class machine with some consumer PCI device like a sound card. I didn't even bother with a USB sound card (even though they all worked on FreeBSD). We transfer the sound to the smartphone. Browsing on such a machine will be devoted to reading scientific and technical articles and documentation (pdf of html), and not watching funny videos.

3 - everything else that you may consider technically defective, we transfer to a phone or tablet: browsing for entertainment, watching videos, software for video conferencing, email clients (I mean email clients for junk mail for all kinds of online stores. In otherwise, for an important mail server I use mutt), instant messengers and other things that are not self-hosted.

In short, we transfer all junk software to a smartphone or tablet. Junk is all the software that you consider as such. The FreeBSD workstation is for serious business only. We will clean workstation of questionable software. The most important thing is that you won't even need to turn on serious powerfull workstation to do something not related to serious work. When I have another bout of purism, I will comfort myself with the fact that all this dubious software is isolated in a smartphone, and not on my workstation.

As for the hardware indicated in the first post - not a server processor, not ECC, not SAS - try something more reliable.
 
As for the hardware indicated in the first post - not a server processor, not ECC, not SAS - try something more reliable.
You are completely right. In my case is a compromise, web browsing and serious computing in the same machine. Soon not anymore possible.

It would be interesting to let android send a remote desktop to a PC.
 
dnb Is this a meme post? You're advocating assembling a $4K USD system to someone reporting issues with their decade old hardware. I suppose it's cool you have all this spare money lying around to over-engineer your at home workstation for 'very serious tasks like compiling `red light center`'. Am I missing an implicit /s somewhere?
 
dnb Is this a meme post? You're advocating assembling a $4K USD system to someone reporting issues with their decade old hardware. I suppose it's cool you have all this spare money lying around to over-engineer your at home workstation for 'very serious tasks like compiling `red light center`'. Am I missing an implicit /s somewhere?
At one time, when I was at university, our professor of economics, Ph.D., wrote in his textbook that buying a computer is always an investment (not in some cases, but always). The economy is a choice from limited resources: a person can refuse to buy many pleasant things, but buy a computer.
 
I'm all for having ECC RAM, but some of the other requirements are out of scope. For example, SAS has no data safety advantage over SATA. In fact any of the 3.5" high capacity drives are identical other than the interface.

As for sound - even a video hater like me occasionally needs information from a youtube video while computing.
 
You are completely right. In my case is a compromise, web browsing and serious computing in the same machine. Soon not anymore possible.

It would be interesting to let android send a remote desktop to a PC.
Android already has those apps on Google Play...

dnb : Epyc processors by themselves cost more than $4k USD... no mobo / RAM / PSU/SSD. I have a Lenovo laptop that is 5 years old, runs FreeBSD 13.1 / Plasma 5.24.5 / KF 5.100, and has 8 GB of RAM. Usable hardware, but I have to be careful to not open too many tabs in my browser - especially RAM-hungry stuff like Discord and ESPN. Compilations fail if they use more than 2 GB of swap. Granted, the processor on that laptop is a Ryzen 5 2500U, but it ran win10 just fine. I'm just discovering that both (web research) and (local processor-intensive stuff) require a LOT of RAM.

At one time, when I was at university, our professor of economics, Ph.D., wrote in his textbook that buying a computer is always an investment (not in some cases, but always). The economy is a choice from limited resources: a person can refuse to buy many pleasant things, but buy a computer.
yeah, and the magic number to budget for a minimally useful laptop is $500: latest-gen r5/i5, 256GB SSD, 8GB RAM... And about $1k for something more usable. As for things being an investment, you kind of have to expect some return on that investment.
 
Yes, that is the alternative: different phone apps for everything. They can do it in the web, but they offer a wonderful, special phone app for their special service. You must install a lot of wonderfull (bloated) apps.
Yes, and sadly that's for a reason. I've been thinking of doing baby steps for interfacing with human users (for monitoring my home hardware, such as pumps and wells). Doing this via the web is super easy as long as you are only dealing with static data that needs to be displayed: Use a CGI script in your favorite programming language to render the information into text, tables, and pictures (graphs), turn them into HTML, send them to the browser. Since browsers are actually remarkably good at displaying these things, you get good displays at minimal programming cost.

When it comes time for the human to interact with the system and control things, that's when it get ugly. Sure, you can keep the business logic on the server, use http POST and forms and buttons and entry fields. Leads to extremely clunky user interfaces, and whole web pages being sent back and forth. With extreme heroic effort, you can use JS (and Ajax and that whole bag of tools, all dull and rusty) to move the interaction to the web client, and interact with the server via sockets (which can be https sockets, to better get through firewalls). Enormous amount of programming work, unless done super carefully by skilled people you end up with brittle solutions. If you think about it, it's clear why: You're using the huge and complicated machinery of a web browser for nothing more than a simple rendering engine, you are writing your user interaction code in a 3rd-class programming language, and there are sockets inserted between human user and system at all the wrong places. No wonder this is difficult and ugly.

The obvious response: Go directly to the OS of the device the human has in their hot little hands (whether it's Android, iOS, Windows or Mac, those being the only choices in the real world), and use the OSes native user interaction tool kits. It becomes relatively easy to write code that does a very good job of interacting with the user, displaying information without being forced into the bizarre DOM of a web page, and being responsive. I've used Kivy a little bit for this, and it allows me to write user interface programs that give clear displays, can react to finger presses, mouse clicks and keyboard input, and the code is mostly portable between platforms (even between phone and computer). If you have limited development manpower, deploying native apps for user interaction is absolutely the way to go.

Now, I'm not knocking the Javascript-in-browser model uniformly. There are amazingly good examples of doing it right. A few of my favorites are the various office apps (whether's is MS 365, Google Docs ...), data analytics tools (Jupyter notebooks are a full python + scientific computing + graphing platform, all in the browser), or map display (try a good map done with ESRI's ArcGis, it works amazingly well). It can be done well, but it requires heroic effort, meaning huge amounts of manpower and discipline.

What do we learn from this? One size does NOT fit all in software development. There is a place for browser-based interaction, and there is one for apps.

And stop worrying about "bloat". You'll pay for the comfort of interacting with the computer. People get upset when they can see the complexity price tag of good user interfaces; you just have to accept that as the price of accessibility (and by that I don't mean for the handicapped, but for most people).

As for sound - even a video hater like me occasionally needs information from a youtube video while computing.
It's a great source of music to listen to. The sound quality isn't great, the ads are somewhat annoying, but the price is right.
 
On the price of laptops: Until last fall, my daily driver at home was a 2008 model MacBook pro, which I bought used in 2009 for about $800 (it was a lease return). If you depreciate that original purchase, it cost me $62 per year; the cost to regularly replace the batteries (about $100 every 3-4 years) brings that up to about $100. Sadly, last fall it disintegrated, when the screen portion of the case came unglued and tore the wiring apart. It did absolutely everything I needed, including some development/coding work; when needing lots of CPU power, I used VMs in the cloud.

Today my daily driver is a 3-months old MacBook pro, which cost about $3000 (due to complex circumstances, I can't buy a used one). I expect it to be used for 3 years, then replaced, at a depreciated cost of about $1000 per year.

Both are roughly equivalent in "user satisfaction", but not in the cost/benefit ratio.
 
I am a big fan of Emscripten (C and C++ to JS, ASM.js or WebAssembly compiler) to port C++ programs.

However I notice that you lose contact a little with "native" web interfaces. You then have to resort to making bindings using "inline JS" which is time consuming and inflexible.

So as much as it pains me to say, Javascript, CSS, HTML are more convenient than C++ and GUI toolkit on the web. Especially since tables (and flexbox) are pretty decent to use for layout.
 
Never use tables for layout
Yes, I was one of those terrible guys who used tables for layout (before flexbox).

It was the only thing I could get to reliably scale (even large companies like Google and Facebook "doing it right" seemed to be less robust than my table based approach).

Plus almost all of my pages are displaying tabular data. Web pages for me are purely to show data. Data is best presented in a table. Or at least that is how I justified it to myself haha.

For example, most sites exhibit issues such as:


w3c_bodges.png


The rigid approach of tables and flexbox does prevent this. Text doesn't flow over so no risk of line breaks. Minimum sizes are computed by the cell data, etc.
 
Not mine.
Yeah, don't get me wrong. I used tables because I am objectively not a good web developer. I can admit that ;)

However I also feel that *too* many people (ironically including those who made the w3c page) are also not good and so should probably use a crutch like tables or flexbox rather than just making broken websites.


David Siegel was the first person to famously start promoting the use of tables for layout way back when. In 1997, he wrote the article, The web is ruined and I ruined it
Hah, that is quite cool. Like patient zero.

Big question though. Would you prefer amateurs using tables clogging up the internet or some framework de jour like bootstrap?
 
Back
Top