Yes, welcome ...
"Welcome to web development 25 years after the birth of the web and ..."
... it's still a monumental ballache to get anything done.
If you travelled back to 1999 and told web developers that one day hundreds of them would pony up cold hard cash to get a feature in a web browser, none of them would have believed you. 1999 was the high water mark of the browser wars between Microsoft's Internet Explorer and Netscape Communications' Navigator. Microsoft was …
IE was also a memory-hungry bug-ridden monster. MS was able to hide the memory issue by spreading IE's components throughout the OS, making it appear lean and light when in reality it tied up system resources even when it wasn't running. And of course the bugs all became holes in the OS, rather than remaining holes in the browser...
It was ever thus.
The distinction between what's often labelled as "native" applications and web applications doesn't even exist an any meaningful way any more.
Ironically, most "native" applications would be useless without a web to connect to and share data through. The Facebook app wouldn't be much without Facebook.com behind it
Hmmm, useless... would that be my office suite, various mechanical / electronics CAD tools, various IDEs and compilers backed by a fully offline-capable git repo - perhaps my Paint Shop Pro, Inkscape, Winamp, KMPlayer, or my ferociously non-Steam collection of games I only ever play as single player...? Which one is it? And what makes you think I have either a Facebook or a Twitter account...? Fair warning: you'll need a reeeeealy long time if you go looking for them.
"Ironically, most "native" applications would be useless without a web to connect to and share data through"
I often wonder whether people who write that sort of thing are actually aware of the reality of what people who use computers in the business and productivity world actually *do* from day to day.
This post has been deleted by its author
As an app and web developer I can say that no, existing web standards are not good enough to be able to give up native code. That's not to say that a lot of standard press-and-select apps wouldn't happily exist online, but the hoops you have to jump through to provide a slick, reliable and immersive experience are quite nasty. Sometimes even apparently simple UIs require that many threads run in close synchronization in the background to ensure everything turns up exactly where and when the user expects them to.
Of course the other issue is one of revenue. If it takes me X weeks to code up a half way decent experience, how do I put it on the web and pay my bills? Ad revenue is a miserable compensation and including adverts only serves to interrupt the user's enjoyment. Paid apps at least connect the idea of some value back to the work you've put in.
On the whole though, the current eco-system and platforms are tending towards lowest-common-denominator experiences. It's painful to develop for the web, and just not worth putting months of work into apps that have shelf-lives measured in weeks. Users bemoan paying for something, even if it provides many hours of entertainment or use and there are no discovery mechanisms for genuinely different experiences.
Regardless, the current crop of browsers do not provide a platform for delivering meaningfully better tools and entertainment to the user.
I don't mind paying for a good application and there is the problem a 'good' application.
since everybody who can string a few characters together became a web or app developer and there is almost no quality control except for user reviews all the app stores are infested with scores of applications that are just not good. A trial version with 1 week to see if you like it and then pay for it would be perfect for me but maybe I am an exception.
Did the author of the article suddenly switch off the grammar and spell checker for this sentence?
Web Components as a standard....seems an awful lot like giving a formal name to jQuery UI's widgets or Kendo or ExtJS and so forth.
At one point, the user and browsermakers were winning. With features like zoom and text reflow, sites became viewable everywhere.
Now, the "request desktop version" option sems to have been killed by these enemies of usability, the non-desktop version has disabled zoom, text reflow, and often traps you in a useless UI that lacks the functionality and content of the real site. Often with letter sizes that could be read from the moon with the naked eye. argh.
My favourite example is a phone support/bugreport website. The site didn't redpond to request for desktop version, the UI didnt allow changing search options, and always only showed unanswered questions, which made every visitor think they were the onlh person with a particular issue, and upvoting/downvoting was completely absent.
As a maker of smartphones, you would've thought they'd test it..
What baffles me more, was that there were discussions about *which* subset of main site should be on mobile site. NO, stop that, I dont want to go back to lugging a laptop with me everywhere all the.time again.
AC so I dont get flamed on said site again for daring to once again request fullfeature site.
why does your bank's website still suck so badly?
Because that would involve, y'know, investing
some a tiny bit of the Scrooge McDuck mountains of cash their management swim in every night. My Bank's site has been the same as long as I can remember (like, since circa 2000) - they'd probably say security but I'm fairly convinced they're using old-school ASP on NT4 servers probably on a Compaq Proliant server, security my ass. It still hasn't been explained to me why their online banking systems have to go down for "maintenance" for an hour basically every night earlier. I don't work in banking and I'd get fired for that level of db downtime, we don't even really rely on them in the same way as banks do so what are they playing at?
why does your bank's website still suck so badly?
I wonder what the author meant by that. I've never really taken a good look at my bank's web site. I just log in, do my business, and log out. As long as I'm able to do that fairly easily, I'm not likely to notice anything else about what's happening there unless it's a security flag. I actually expect them to have bad taste, banks usually do, but the site is always up and always works. Now if they decided to do a "wait for youtube and a thousand trackers" approach, I be getting mad.
What am I missing here? From the linked 'Treehouse' site, 'responsive design' seems to be basically how HTML has always worked (except during the dark periods when idiots designed everything with fixed with tables, 1X1 spacing gifs, and the inevitable footer 'Best viewed in Internet Explorer at 800x600 resolution")
The site goes on to say:
What is responsive design?
Let’s just get right into it: Believe it or not, the Treehouse blog that you’re reading this article on is actually a responsive design! To see it in action, open this article on a desktop browser and slowly make the browser thinner and wider. You should see the layout magically adjust itself to more comfortably fit the new width of the browser, even if you make the page as skinny as the resolution
Apart from the image rescaling (which anyway could often be achieved by [admittedly a bit of a hack] using a %age dimension) what is new here?
http://blog.teamtreehouse.com/beginners-guide-to-responsive-web-design - A site that is full of pingback comment spam, and incidentally does not 'magically adjust' as they claim on my tablet.
What's "new" is that the use of css 3 @media queries to alter the stylesheet depending on the dimensions of the window or the device it's being used on. They're an expansion of the css2 @media query, which was rather limited.
As for your tablet, try turning it from portrait to landscape and back. The difference should be enough to fire off the media queries.
You're right, that is how HTML always worked, except that it only worked for more or less flat text, Wikipedia being an excellent example. Complex layouts with multiple navigations and menu bars, images that dovetail with each other to produce a magazine style result don't reflow easily and end up requiring four way scrolling and zooming in and out. "Responsive design" changes the style sheet based on screen size and shape to optimise the layout and try to target it to the dimensions of the device being used.