zoidsoft wrote:One way to combat the practice of bandwidth slicing (the practice adding increasing numbers of users to the same capacity pipeline) by ISP's is for web developers to return to the programming practices of the 90's. We used Gif's and went to PNG's due to superior graphics and reduced size (and because of CompuServe's stupid patent that expired in July 2004), but when capacity increased, webmasters abandoned conservative bandwidth practices.
I don't want to derail this thread into something overly complicated or technical, but one of the 'problems' with returning to using Gifs is that clients and marketing people would simply never allow it, indeed neither would the end user. The reality is that today we have tablets and phones whose resolution sometimes go beyond the average television screen, and using gifs or low resolution solutions like gifs simply wouldn't be feasible as it would degrade from the user experience. In addition, many modern requirements for transparency put gifs out of the question, as their transparency is simply not appropriate for modern web experiences.
I think instead the route that web developers need to take, and are taking (at least in the UK and Europe in general) is to reduce HTTP requests, adopt more semantic HTML, mix adaptive and responsive imagery to tackle lower resolution devices (ie feed lower resolution devices lower resolution images etc) and also to take advantage of the latest CSS and HTML properties and adopt a graceful degradation approach rather than a "This must look the same on all browsers/devices" approach.
With that in mind, we no longer need to use gifs for rounded corners etc. - we can use CSS to do this and if you're using an older browser you get an older experience and will not see the rounded corners. In addition other uses of SVG and generally vector based graphics all reduce the http requests to the server and ultimately reduce the bandwidth required to serve the page.
Whilst it is true that web developers lost sight of controlling bandwidth for a while, this largely changed with the advent of the mobile market, where web pages are increasingly encouraged to be responsive or responsive-adaptive (ie, the same HTML structure but serving different css and images) to reduce building costs but still must account for poorer bandwidth due to people connecting wirelessly.
As for mobile apps, again the thing to do is to reduce the necessity for HTTP requests by moving assets such as images to the app itself, so that they do not get served from the server but from the app's repository on the device itself. In addition, logic for the calculation of planetary positions etc. would all need to be moved to the device itself (ie, not served remotely) and saving would have to be done locally too - in other words you could easily create an app that NEVER needs to access the server to operate and run its functionality, this then allows access to the server to be optional - such as the use case of synching your app to some server/cloud based database.
In other words I do think that there is a problem present but I think the solutions are probably much simpler in a way by changing the approach to the problem rather than resorting to adopting the same strategies as in the late 90s. Of course the major problem with developing for operating systems is the lack of financial viability from a standard business model, but once again, people overcome this by offering premium solutions and by working alongside advertising. But it still a potentially unprofitable solution due to the need to create code for every OS (one for iOS another for Android another for [insert next big thing]) or use solutions like PhoneGap which work across devices but can suffer from, at times, being clunky/slow.
Either way there are solutions to these problems but ultimately they may not make custom web apps all that attractive as a solution but this may be more a symptom of the the changing times, and perhaps we can no longer expect the same returns from software as we once could have for desktop only solutions.
) with Astraea...