Hi,

This is probably one of the big reasons I dislike (hate is a bit harsh) the current state of the internet - it's all a bandwidth hog forcing everything to be slow. And seeing that just about every second website is a near "web application" makes the matter even worse.

Here is a breakdown of bandwidth used loading various websites (one web page only). The results are rather alarming!! In every case the actual document content is a fraction of the total bandwidth. JavaScript (most popular in this sample being jQuery) being the biggest bandwidth hog.

So next time, don't just blindly throw in various JavaScript frameworks to make your web app or website look good. Think about the bandwidth being used per loaded page too. Optimising and reducing the amount of JavaScript will clearly improve the loading time and responsiveness of you website.

http://mike.teczno.com/notes/bandwidth.html

So has anybody done some bandwidth breakdowns of there FCL-web based websites or web applications? How do you fare?

FCL-Web by itself does not create bandwidth hogs. It does not tell you what to send to the browser. So All depends on what you do with fcl-web.

Javascript is not something you can avoid. People have come to expect a certain functionality from a website, which can only be delivered with Javasvript. If you don't provide it, your product will not sell. It's as simple as that.

That said, Javascript is not all bad;
Depending on what you do, it can actually save you a lot of bandwidth by saving complete page reloads.

Michael.

On Tue, Mar 27, 2012 at 4:13 AM, Graeme Geldenhuys

So has anybody done some bandwidth breakdowns of there FCL-web based

I have an entire cloud platform developed in FPC/Lazarus and studied my framework and the impact code size has to do with low-bandwidth. Latency was dramatically reduced by two ways. The single largest impact was the use of the deflate compression methods for all calls via core objects. Deflate adds a compression layer on top of the http packet. So contentlength is reduced , inflated and then processed by the client or server.

The second is javascript development. You should make sure you can re-use code wherever possible..

The core system in my platform is similar to fpweb but my sockets implement is a custom engine I've developed over the course of 14 years. But knowing how fpweb is handling requests adding a Deflate option for requests/responsces would be simple and highly beneficial to all parties using fpWeb.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120327/47908b67/attachment-0001.html>

Indeed.
All it takes is to implement it in SendResponse.

Michael.

So next time, don't just blindly throw in various JavaScript frameworks to make your web app or website look good. Think about the bandwidth being used per loaded page too.

It's not only bandwith. I only use Firefox with NoScript addon which prevents my browser from executing (Java)Script content. There are only a very few web pages where I have switched it on. Nearly every page I visited that did not display correctly without scripting was a was very obscure (to say the least) junk page. (Java)Scripting is the main mechnism to spread viruses and trojans today.

So pages with scripting would not reach me. I would click to the next one immediately.

Javascript is not something you can avoid. People have come to expect a certain functionality from a website, which can only be delivered with Javasvript. If you don't provide it, your product will not sell. It's

as simple as that.

I doubt that. Just the opposite: A web page which uses scripting will not be displayed when NoScript is on. So you don't reach all possible customers. In the past I often prefered web shops that worked without scripting to others that required it. And these shops prooved that scripting is not needed to provide the essential things in the web: Information. Those who just want to view TV should do so. And those who want to play games should do so too. I just want information in a clear and fast way. If someone wants to sell me something just inform me about the product but don't play unmeaningless videos or such garbage.

Believe me, I will reach far less customers by not using Javascript, namely: zero.

I make a distinction between websites and webapps.

We do not make general purpose websites, but web applications for a specific audience. There is a huge difference.

These applications must behave and act as a desktop application, this is a requirement. This is not possible without Javascript.

Then you may ask, why not simply program a desktop application ?

Simple: people do not want an installer or updater.

If it was not for that small detail, I would not touch web programming with a long stick. No set standards, different and ever-changing browsers, a language that sucks big time. But alas...

Michael.

I agree with the sentiment and the first browser I use has Javascript disabled. But when I last saw this argument elsewhere somebody tried to make the point that scripting was evil by saying that NoScript had something like 3 million users, which was trumped by the argument that that leaves several hundred million browsers without it.

2012/3/27 Michael Van Canneyt <michael at ...>:

These applications must behave and act as a desktop application, this is a requirement. This is not possible without Javascript. Then you may ask, why not simply program a desktop application ?

LOL, you took the words (or rather question) right out of my mouth.

Simple: people do not want an installer or updater.

With Object Pascal / Delphi based apps, it is quite possible to have a no-installation required product. There are already many like them. And just about every product has a "check for updates" feature, and many of those do silent updates without the end-user ever knowing. So in truth, web apps are just the "flavour of the month" for now - until the next big thing. Lets hope I can get through this phase without a client requesting a web app.

PS:
I've ported one of tiOPF's older Support Apps, which is a automatic distribution and update system. This does exactly what I described above. It even has a nice Release Management interface to define what must be bundled in a release/auto install or update. Just a bit more code clean-up and some vital documentation needs to be added, then I'll make it available in the tiOPF repository.
If you can convince your customers not to be "web app lemmings", then maybe this is your way back to desktop applications. :-)

I heard this one before.

Answser: Not a complex one like ours. We update almost weekly. So, we do have an automated updating feature. But then:

1. We use client/server technology.
Meaning that sometimes, the server says 'update NOW', whether client is ready for it or not.

Simply because sometimes the data model at the server end has changed and a non-up-to-date client will bomb out with errors. And this kind of update happens at least once a month.

2. Users work in a protected environment, meaning that they have no rights on the machines.

1 combined with 2 means that the sysadmin must once a week visit all PCs to upgrade when we update our server. Clearly, this is not feasable.

So, we instruct all sysadmins to open the installation dir for general read/write access. They're not very keen on doing so, and rightly so, but they do it.

I'll be glad to look at it.

If you can convince your customers not to be "web app lemmings", then maybe this is your way back to desktop applications. :-)

I'm afraid it is too late for that.
In corporate environments, you cannot get out of the web app hype, like it or not.

Wait till they ask for integration with Google docs and Microsoft Live. (or office 365). Then the real fun starts. Google is easy, MS is a mess :(

But that's way off topic.

Suffice it to say that when the need is there for web technology, fcl-web by itself does not impose huge demands on your internet connection.

Michael.

Michael Van Canneyt wrote

1. We use client/server technology. ? Meaning that sometimes, the server says 'update NOW', whether client is ready for it or not.

That's when you slip them the "silent update" version, which updates before the app launches (no need to notify or ask the end-user). They'll just think their computer was slightly slow that one time. Yes, I think that is morally wrong, but in corporate environments you can get away with that, simply by calling it "IT Policy". ;-)

2. Users work in a protected environment, meaning that they have no rights on the machines.

Again (and as you stated), in corporate environment you can overcome this with the same "IT Policy" or "System Requirements" phrase. Running from, and updating to the users $HOME folder should be a place with read/write access (many applications require temp or config files) - unless the sysadmin is seriously paranoid.

But over all, I understand what you are saying...

Wait till they ask for integration with Google docs and Microsoft Live. (or office 365).

Yeah, my boss was all for Google docs too, until we had an ISP outage! Oops. Suddenly the whole "cloud computing" thing became a "do not go there" sign. Not to mention that you entrust your private data with somebody you don't know, and have no idea how good or bad there security setups are, or knowing that they can freely scan and search your private data without tell you. I'll not entrust my personal or confidential company data in any cloud any time soon - make that never!

Suffice it to say that when the need is there for web technology, fcl-web by itself does not impose huge demands on your internet connection.

Agreed. Just for the record, I did not imply that using fcl-web is a bandwidth hog. I just thought the research was interesting for those developers that write web apps. jQuery is so often used in such cases, but is the biggest bandwidth hog of them all. Having this knowledge means you can try and take steps to improve your web app download and response times (cut some jQuery fat, use compression and so forth)

...And it does not matter what platform they are using, it will work without problems. No drivers needed, no libraries needed, no version issues.

Javascript will not go away, it will become more popular over time. This is the trend the last ten years and it just gets more popular as more and more Java apps are ported over.

It saves huge bandwidth (not to mention responsiveness and client side speed)to use javascript apps client side with modern browsers. You download the data and until it changes you do not need to talk to the server other than some update checks on the data if it is multi-user.

I can not emphasize enough how much time it saved for me to do my projects as javascript (ExtJS based) web apps (using fpweb server side back-end). No matter if the client is Mac, PC or mobile device, it works.

As for NoScript addon usage, I am using it too. If the web app I need to use needs Javascript, I enable that one website (but not letting google, and the other crap ad companies to run scripts). You can not get around this. But you need to be pretty aware of this and manage it manually which is not for 99% of web users.
A few million NoScript users does not hold a candle to the hundreds of millions without it who does not even know what Java or Javascript is. This is the way the internet works, and it will not change people as the past 30 years show.

AB

ABorka wrote

Javascript will not go away, it will become more popular over time.

The same was said for DHTML, then Java, then Flash, then Silverlight (God knows who uses that)..... now it's JavaScript's time to shine.... until the next big things arrives. This is just a sad fact of internet/software evolution - the only constant is change.

It saves huge bandwidth (not to mention responsiveness and client side speed)to use javascript apps client side with modern browsers.

About that responsiveness... not all Javascript enabled websites or web apps are created equally. I have seem rather simple websites that bring my Quad Core to a crawl when I scroll the web page (with huge lag). Then I have also seen other way more complex web pages scroll very fast. Go figure. :)

Personally I still think Java applets (or Java apps launched via the web) are way better than web apps. They can be cached locally for quick launches in the future, way more responsive, full featured with the whole Java API at there disposal and the identical code can be used for desktop application versions too. But that's just my 2c on the subject. ;-)

Javascript is by far the most efficient way to implement cloud apps. Just so you know... Web browsers can do cache control - and - web applications can have a cache manifest file which causes the browser to maintain it's own copies of files and even tell the browser when to bypass cache (for back-end system calls)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120327/1c4af2bc/attachment.html>

That's a joke ?

[ for those not interested, hit 'delete' now! ]

Let me present: "A year in the life of a web developer"

4 Apps developed and working perfectly in FF 3.6, Chrome, Safari on Mac OS.

Comes along tester with version 5 of FF. Bang, all broken.

Tester comes along with IE 6/7/8 - Bang, all broken.

[test again in ALL versions of ALL browsers]

[1 week later: OK, let's drop IE 6, that's REALLY old]

Comes along tester with version FF 10, bang, app AND Firebug debugger broken.

Apps deployed.

Early adopter user with IE 9. Half the screen does not function anymore.

[searching internet forums] Oh shite, ExtJS 3 does not support IE 9.

[solution found:] Damn, need to upgrade to version 4 of ExtJS.

[reload app with extJS 4] Ow crap, the WHOLE ExtJS api has changed.

[Gradually the truth sinks in:] Backwards compatibility: 0,001% and sinking...

[6 weeks of work reworking 4 apps *from scratch*]

Not to mention all the fine-tuned, pixel-perfect CSS that needs to be reworked 100% and tested in all versions of all browsers - because the web always looks nice and hip.
We outsourced all that, and that costs us more than the initial development.

Then some braindead safari user on a iPad cannot type a . in a numerical field because his internationalization settings are screwed up - again problems.

The list continues. And all of this is REALITY, not made up.

[Stay tuned for more fun in webland with our next requirement, problems guaranteed:] Have the login in the browser work with the Belgian E-ID card. Meaning: Java needed in the browser, smartcard reader support needed, at least JDK version XYZ, by default NOT installed in IE and whatnot.

From my point of view, the versioning problem just got a lot worse.

The Windows OS and API is a haven of tranquility by comparison, and the lord knows we cursed MS many times.

So, no, in my experience, web is definitely not better than desktop. I guess it depends on the kind of website you're trying to make....

But now I really stop; it's getting really OT.

Michael.

Let me guess: You pulled the plug to make a statement? ;P

Regards,
Sven

I agree. I never understood how public services could even be allowed to place work product in the hands of Google or Microsoft. These two search engine companies make BILLIONS from information brokering. Data is king (to them) and money just comes as a natural consequence.

Anyone who thinks their work product is safe in Google or Microsoft is just opening themselves up to fleecing (without them even being aware).

I'm betting that their is a market for private cloud and I'm selling cloud ownership.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120328/1cb614eb/attachment.html>

Semi-rebuttal (as I'm not a fan of The Cloud either) - they store the data in secured datacenters, and probably encrypted too, for storage AND access. They have redundant power, internet links, infrastructure, dedicated to-the-case staff ;) and so on.
Yes there is market for private cloud for companies that would go to all lengths to /not/ sell their data to Google or MS, AND have enough monies AND brainpower to match such setup, to ensure at least same level of service (i.e. having a bunch of obscure innocent looking boxes distributed around the office block unassumingly is not the name of the game for them any more)
http://xkcd.com/908/

L.

Yeah, everybody said the same think about Sony (which is definitely not a small company) and the PSN network. But oops, somehow the lost a few million users's data overnight. No thank you!!

I read the other day about another similar scandal. Millions of users entrusted there accounts and banking details with some internet company, only to find out it was hacked. Then later it was leaked that the system managing those account details was a plain jane Win98 PC. Oops again.

Anyway, each one to there own I guess.