The original vision didn't address the sort of interactions that users (and providers) would want. So, the Web has just become a delivery vehicle for virtual machine applets. In that sense, it is doing an admirable job adjusting to constantly evolving interface demands.
[Imagine gopher(1) trying to do all this!]
Witness the number of cross-linked sites that most pages access just to "deliver" a page's content (cuz they aren't *giving* you something but, rather, trying to TAKE something FROM you!)
The bigger "threat" is the recognition that more folks consume content using phones (tiny screens, piss poor user entry). It won't be long before we find pages that really only make sense in a phone's aspect ratio! (there is some skill required to build pages that can be equally accessible in a wide range of form factors, etc.)
"Under the hood, SeaMonkey uses much of the same Mozilla Firefox source code which powers such products as Thunderbird. "
It's what is under the hood that counts. Even Opera dropped Presto and started using chromium code.
I use Brave, another child of chromium, on most of my machines. I have it on this box but it is an older version. Updating is problematic since it's OpenSUSE 13.2 from 2014. I missed leaping to Leap so at this point it would be a clean install. The hardware is the same vintage. I'm definitely in the 'if it ain't broken' camp.
Vivaldi is an interesting one. When Opera switched from Presto they also dropped many of Opera's distinctive features upsetting the fans. Vivaldi replicates those features despite also being a chromium derivative.
There's a whole cottage industry in cross-browser testing. Speaking as a developer rather than a user, it's a pain. One bright development was when MS redid Edge to use the chromium code. If there was one browser that was guaranteed to break whatever you were trying to do, it was IE.
Long ago, I made the decision that I wanted control over presentation instead of flexibility in presentation. This imposes on the viewer/user to have a suitable "presentation device". But, makes MY job *so* much easier. I can concentrate on what I want to say/show instead of having to anticipate how many different "compromises" will be imposed in the rendering.
E.g., I often put animations in PDFs to better illustrate some concept in an interactive manner. Hoping that the user can render that animation on their "browser" just makes more work for me. Wanna view it on an incompatible browser? Then you get a substandard document. Too bad, so sad.
Likewise adding audio to a (typically) "visual" presentation. E.g., to illustrate how words like "mash" are pronounced differently in different regions (to say something "rhymes with bash" is ambiguous)
Seamonkey may share some source with Thunderbird, but the browser wrecks Canadian Tire in a completely different way.
It also does not seem to be able to use Firefox extensions, such as AdBlock Plus, Audio Equalizer, I Don't Care About Cookies, and Javascript Toggle On And Off. The last one is especially useful to block logon requirements on many web pages. You just click on a small icon in the upper righ corner of the screen. The Seamonkey version is extremely cumbersome:
SeaMonkey might as well be a completely different browser.
I actually never use SeaMonkey for browsing. I only need it when receiving an email that I must respond to that uses HTML. My regular email client is Pimmy 3.5, which is plain ASCII text only. It does not understand HTML, and is immune to <IFRAME> attacks.
It also handles an unlimited number of email addresses, which I use to eliminate spam. If a site begins sending me spam, I merely delete it from my list of email addresses. You can generate your own list at
formatting link
I rarely get spam anymore. I once wrote my own spam filtering program using Bayesian filtering, but it was simply too much work to keep up with changes in spam messages and new techniques. The combination of Pimmy and e4ward is much simpler and permanent.
Forget all my rants about SeaMonkey. I just deleted it.
I found I have another email client that handles HTML. It is Opera Mail V1.0 and is on another VirtualBox operating system. It works very well and is easy to use.
I love VirtualBox. I simply could not survive without it.
On a sunny day (Wed, 27 Apr 2022 05:03:40 -0000 (UTC)) it happened Mike Monett snipped-for-privacy@not.com wrote in <XnsAE86ACBC856Didtokenpost@144.76.35.252>:
FYI I have been running adblock plus for 10 years or more on seamonkey its a great browser, but no raspi version yet I know about.
Audio Equalizer,
Wrote my own audio equalizer:
formatting link
no need for browsers
I Don't Care About Cookies, and Javascript
fetchmail here to get email, been using it since 1998 together with pine to read it.
I like 'spam' or rather advertizing, shows my system is still working I have near unlimited email addresses... I assign every company its own, so if 'spam' comes in I know who it was and either unlist or warn them they have been hacked.
It is good in tracking the bad guys too as recently shown.
All my editing and coding is done with 'joe' text editor.
An this is posted with NewsFleX ported to and running on a Raspberry4 8 GB. Written the code so full control :-)
formatting link
any of you guys ever publish any code>?
Chromium works OK on this very small computah too.
On a sunny day (Tue, 26 Apr 2022 14:09:25 -0700) it happened Don Y snipped-for-privacy@foo.invalid wrote in <t49n2e$9p3$ snipped-for-privacy@dont-email.me:
I dunno, I prefer the phone format as info in text form is mostly all you need. examples:
formatting link
for the news in (German) or
formatting link
for Smithsonian program listing for TV
You can always use ctlr + or ctrl - or ctrl 0 in your browser to enlarge it etc a decent browser will remember the enlargement settings for each site/.
No ads. Basic HTML. I build my own website with basic HTML: panteltje.com No advertising and no java.
That stuff is not normally needed, one can always make a youtube video if more info is needed. Interactive? Download and compile my code :-)
Have a local copy of the site running on Apache server, I test new entries locally first, then it goes to the site.
There's always room for creativity. Dealing with browsers is like playing whack-a-mole. A long discussion during our Monday meeting concerned cut'n'paste and the relationship between the browser and the Windows clipboard. FF is different to the chromium based browsers, so how to fix a FF bug without creating a further cascade of bugs? It's never the big things just ongoing annoyances.
We're developing a product that has to be presentable. Canadian Tire is selling tools and tires, not a web application so they can be a little more cavalier. Their customers grumble a little and use another browser. Ours grumble a lot and refuse to switch. In one case it was because another application didn't work except with xxxxx browser.
Come on, it isn't that hard to make something that works in any browser. Of course, you have to avoid using all these snazzy features that web development package writers are so fond of. That shouldn't really be a problem, because most of those features are irritating anyway. We don't need animations, we don't want complete remakes of the user interface, we don't want JavaScript where straight HTML will do. Simple is best.
"Everything should be made as simple as possible, but not simpler."
The problem is when "simplest" exceeds the capabilities of "straight HTML".
You don't want to have to take a round-trip to the server each time a user changes a field/control on a page/form. So, you push that logic to the client side -- script. It's nice to be able to do an INTERACTIVE search on Digikey's site -- instead of having to make selections and take another trip to the server to see how those selections affect your NEW choices. (I suspect you'd quickly tire of having to RESUBMIT each time you were unhappy with the choices left to you from some previous choice made)
The problem is that applications are trying to use the browser FOR the UI. And, in order to get the responsiveness that users expect/demand/require, that means doing local, client-side processing.
Sadly, the automatic code generators seem to create lots of cruft just to get some "basic functionality" in place. (and, you wouldn't want to pay someone to hand-craft these sorts of VERY VISIBLE interfaces)
My goal is to convey information to the reader/viewer. As much information as possible in as expressive a form as possible. Note that I'm creating references, not transient "interactions".
I figure the reader should be willing to make an effort to *consume* that information. If he wants to be lazy and opt for some ineffective mechanism, then HE should bear the cost of that poor choice.
Good luck reading that schematic on your iPhone! Or, perusing that long, multicolumn table. :>
All depends on what you're doing. If you're building a browser based highly interactive computer aided dispatch system to parallel a legacy desktop suite of applications you're not going to get there with static html pages.
But what's the motivation for a browser-based solution? Are you trying to have a "no install" application (which makes it immediately available to EVERY seat)? Or, streamline maintenance (server-side updates)? Or...?
Is this just another repeat of the centralized/distributed cycle (mainframe->workstations->server/clients-> ...)
All of the above... In the last few years I've been seeing a lot of RFP's calling for zero footprint solutions. Some of that is justified paranoia about hacking. They don't advertise but an embarrassing number of sites have been pwned. Zero footprint means you can lock the workstations down tight and not let the users wander off to watch cat videos or whatever.
They've backed off the cloud based fad. AWS has dumped often enough to take the shine off that. Losing Twitter for a couple of hours, no big deal. Losing your emergency response dispatch system is something else. Technically you're building a private cloud on premises and assuming the costs of buying and maintaining HA servers. That is the selling point of Azure/AWS etc -- let us worry about all that -- which is fine until it isn't. The other problem with the cloud is sensitive information. There are providers that offer secure installations with fully vetted personnel but that adds cost.
If you've looked in a police car, fire truck, or ambulance lately they are fully wired. Have to physically update a couple of hundred mobile laptops is a problem. Even updating desktops in the dispatch center can be tricky. You try to pick a quiet time to take stations offline one by one and hope there isn't a mass casualty incident.
Most certainly. IBM's revenge. Money is always an issue and with a thin client you don't have to go overboard on the computer and can put the money into big 4K monitors.
formatting link
Not our system but scroll down a little and that's a typical dispatch center. Those people love their monitors. The more the merrier.
So, you're using the browser to give you the functionality of an "X Terminal"? But, you're still letting that build on a COTS OS (e.g., windows)? Does the user *need* the "generic PC" to be present IN ADDITION to the browser? I.e., why not replace the OS and browser and make a dedicated appliance (with deliberately limited functionality)?
Or, do you want MS to deal with the "multiple vendor support" issues (so YOU don't have to develop network and video drivers for an unlimited number of potential hardware configurations)?
Hmmmm... that's an interesting observation (the whole "cloud" idea struck me as seriously flawed)
So, do you deploy the server-side code on commodity hardware? Or, "certified" (commodity) hardware -- so you have some control over that performance?
If "local", then the trip to the server isn't as costly. So, why not move everything into the server (eliminating script altogether)? Or, does that solution not scale adequately (i.e., you're relying on the clients to effectively share some of the computational load)?
I assume you aren't deploying personnel to each site but, rather, doing remote administration? Presumably, you've got that locked down tight so *you* aren't the attack vector? (all traffic in an encrypted tunnel?)
But you're NOT updating those things, right? That's the whole point of pushing script into the clients "on demand"...
Instead of something truly minimalist (like a Sun Ray), you're relying on the browser to give you "advanced primitives" that you can invoke, via script?
But, by doing so, you are now at the mercy of the browser(s) that you want (?) to support.
Yeah, I fully embraced the thin client ideology many years ago. It made maintenance SO much easier! (By contrast, my workstations incur LOTS of maintenance). My current project relies completely on a bare bones client -- more like the Sun Rays than a browser or even an X Terminal (so, NEVER a need to update the client!)
Yeah, it's addictive. I run 5-6Kx2K on my workstations. The limit being how much I can take in with my eyes WITHOUT moving my head (the "tennis match" syndrome gets old, quick!)
Someone will invariably lament that the latency is too great for games (or some other ENTERTAINMENT-related activity) and push to put more "programmable features" in the UI.
Until that bloats to the point of a real workstation -- which will restart the cycle....
Enough is never enough -- esp if you can rationalize someone ELSE paying for it!
Simply put, because they don't care or the website was developed by someone's cousin's kid. Looking at their page source they're not doing anything fancy.
There might be a clue with the various references to apple. It may work like a charm with Safari.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.