Software Bloat

This whole Electron stuff is a plague (and it seems especially Microsoft is excited using it, see VS Code, Teams, Skype, ...). Yes, it's portable "in theory", but the result still has stuff compiled for the target platform, so with closed source projects, you still only get the platforms supported by the vendor.

The whole idea reminds me of a bad idea that was around like 10 years ago: ASP.Net WebForms. Back then, Microsoft had this "great" idea: Hey, every developer knows how to develop an event-driven desktop app, so let's make developing a web app the same. The result was pure horror. Sure, you had this programming model "add an event handler to the click event of this button" that somehow worked in the backend (on the server). But the price was, among other crap, a huge "viewstate" blob doing each roundtrip in a hidden form field…

Now, Electron seems to be the same "great" idea, but into the other direction: Hey, every developer knows how to develop client-side web apps with "awesome" Javascript frameworks, so let's just make development of desktop apps the same. History repeating, still crap.
 
dd_ff_bb What you are doing is describing what XHR is used for. What the other poster was describing was XHR being God's gift to the internet and the universe, world peace and ending hunger. XHR is not that. (I may have exaggerated the previous claims.) It is a function that does one thing and does it well. It does not prevent visual stutter and a lot of the things you list are not done by XHR but other processes not involving XHR at all.

XHR can send and receive your data in the background. How it gets handled and displayed is entirely other processes. That's why I said you shouldn't give XHR more credit than what it deserves.
 
My favorite comment by one of the Chromium project members:

I don't see anything out of the ordinary in the trace. The mouse moves are fired at a frequency of 60Hz. There does appear to be a lot of javascript listeners for mouse out, over, move so I imagine that is a fair amount of the work being done. Over for the input team to look at the trace further.


Chromium must be for sure a premium quality code base originating at thedailywtf.com!
 
Hasn't everyone been told that desktop apps are dead and browser based apps are the future? If so, then what's the reason for Electron, or desktop apps do have a future?
Electron allows you have almost a single code base for your Web, desktop, and most importantly phone apps. See how Discord does it, for example:

Again it comes down to minimizing the number of programmers you need, and the skills those programmers have to have.
 
dd_ff_bb What you are doing is describing what XHR is used for. What the other poster was describing was XHR being God's gift to the internet and the universe, world peace and ending hunger. XHR is not that. (I may have exaggerated the previous claims.) It is a function that does one thing and does it well. It does not prevent visual stutter and a lot of the things you list are not done by XHR but other processes not involving XHR at all.

XHR can send and receive your data in the background. How it gets handled and displayed is entirely other processes. That's why I said you shouldn't give XHR more credit than what it deserves.

The snippet you quoted me on (post #85):
XMLHttpRequest are essential components for exploiting the clients' browsers to their fullest potential

The full sentence I posted (post #83):
Javascript manipulation of the DOM and XMLHttpRequest are essential components for exploiting the clients' browsers to their fullest potential, and for providing smooth and dynamically changing user interfaces, with minimal network I/O.

But you're right. Even javascript isn't likely to end world hunger, and XHR alone will not prevent visual stutter. It takes careful painstaking programming, and a lot of implementations I've seen just don't do it right. I don't use any of the popular AJAX frameworks discussed above, and don't recommend them to anybody. You and I might not see eye to eye about javascript in general, but you make good points overall.

Hasn't everyone been told that desktop apps are dead and browser based apps are the future? If so, then what's the reason for Electron, or desktop apps do have a future?
I'm also not saying that desktop apps are dead, they just aren't my specialty. There's more than one way of doing things. I like writing browser base apps, but desktop apps have no doubt improved a lot since I retired. I'm just one more old dinosaur, who is not at all up to date on desktop apps. Programming is just a hobby for me now. Something to keep me out of mischief in my decrepitude.
 
drhowarddrfine, Glad I found this forum to keep me up to date on a few things I'm still very interested in. My brother calls this being "hooked on the game." But I have to admit I don't understand, or try very hard to understand, about half the thread topics that get posted on this forum.

For all of the 28 years I was a programmer, I found I had to learn a whole new set of skills every 3-5 years just to keep from becoming completely obsolete.
 
Somehow I would not be surprised should someone implement a http subprotocol for lean client/server apps that would smell strongly of X11, with some buzzwords thrown in...
 
Somehow I would not be surprised should someone implement a http subprotocol for lean client/server apps that would smell strongly of X11, with some buzzwords thrown in...
You jest, but web apps are already directly analogous to X11 or DisplayPostscript. They only lack separately controlled windows.
 
Ahh.. I'd like to chime in, and say that software bloat is frankly a vicious circle. Yes, it's possible to do sound on a device that has just a few MB of RAM - but then we want more features from the same setup. We want the sound output to go anywhere on the device, we want the sound quality to not degrade while being transported to output device, we want sound in response to something happening on the device, and we want 16-bit sound, not 8-bit. All that makes the original hardware unable to handle the new requirements for sound - it just takes too many bits. Oh, and don't forget the security around the sound subsystem!

So, you can do something small and simple, but it won't be up to snuff in the modern world. 😩 Gotta get on the big-boy bicycle, buddy.
 
Learned COBOL 35 years ago but have forgotten most of it. Too much other furniture in the attic.
COBOL was already 35 years ago a dated and ancient language. Its beauty lies within these two points:
  • there was and is still a massive base of programs mostly in big companies, banks/insurances and public authorities around with ancient code base (often 30 years and more) at important places in their infrastructure where you cannot replace that system easily
  • there are not many programmers around who have mastered COBOL,
  • additionally many COBOL programmers are going in retirement right now.
This was true 35 years ago, and still is true until today. So if you are fluent in COBOL, you will not run out of business anytime soon. And you will have not the need to learn a new language every few years, because the COBOL legacy will keep you busy for a long, long time.

Or as the ACM puts it: estimated 3 trillion US$ flow day by day through COBOL systems. In 1997 the Gartner Group estimated that 80% of the world's business ran on COBOL with over 200 billion lines of code and 5 billion lines more written anually.

 
COBOL was already 35 years ago a dated and ancient language. Its beauty lies within these two points:
  • there was and is still a massive base of programs mostly in big companies, banks/insurances and public authorities around with ancient code base (often 30 years and more) at important places in their infrastructure where you cannot replace that system easily
  • there are not many programmers around who have mastered COBOL,
  • additionally many COBOL programmers are going in retirement right now.
This was true 35 years ago, and still is true until today. So if you are fluent in COBOL, you will not run out of business anytime soon. And you will have not the need to learn a new language every few years, because the COBOL legacy will keep you busy for a long, long time.

Or as the ACM puts it: estimated 3 trillion US$ flow day by day through COBOL systems. In 1997 the Gartner Group estimated that 80% of the world's business ran on COBOL with over 200 billion lines of code and 5 billion lines more written anually.

Even if you bother to learn COBOL, are you gonna be trusted to write code that protects about $1 trillion in World Bank assets? We all know what happened when a disgruntled programmer broke the Internet. ;)
 
COBOL was already 35 years ago a dated and ancient language. Its beauty lies within these two points:
  • there was and is still a massive base of programs mostly in big companies, banks/insurances and public authorities around with ancient code base (often 30 years and more) at important places in their infrastructure where you cannot replace that system easily
  • there are not many programmers around who have mastered COBOL,
  • additionally many COBOL programmers are going in retirement right now.
This was true 35 years ago, and still is true until today. So if you are fluent in COBOL, you will not run out of business anytime soon. And you will have not the need to learn a new language every few years, because the COBOL legacy will keep you busy for a long, long time.

Or as the ACM puts it: estimated 3 trillion US$ flow day by day through COBOL systems. In 1997 the Gartner Group estimated that 80% of the world's business ran on COBOL with over 200 billion lines of code and 5 billion lines more written anually.

haha wtf I had no idea this was such a huge issue
 
Ahh.. I'd like to chime in, and say that software bloat is frankly a vicious circle. Yes, it's possible to do sound on a device that has just a few MB of RAM - but then we want more features from the same setup. We want the sound output to go anywhere on the device, we want the sound quality to not degrade while being transported to output device, we want sound in response to something happening on the device, and we want 16-bit sound, not 8-bit. All that makes the original hardware unable to handle the new requirements for sound - it just takes too many bits. Oh, and don't forget the security around the sound subsystem!
I'd more of break bloat into 2 categories. One being more of feature creep, of adding everything including the kitchen sink into a package, because of new or "shiny". The other being more of adding more layers (middle-mans) into the work; when you can just as easily do it without all the additional layers.
 
Unix itself would barely be recognizable if feature creep had been the guiding factor, could u imagine if u had a single program on your machine that did everything in /sbin ? Perfectly doable, but would be a nightmare.
 
Back
Top