Hacker News new | ask | show | jobs
by cbs 5373 days ago
>'Web apps' have had a fantastically valuable feature nearly never mentioned. If we make big changes in how a Web browser client interacts with a Web server, then we risk getting rid of this fantastically valuable feature and seriously hurting our Web apps and the growth of the Web.

>I believe that if we don't recognize the fantastically valuable feature, then the rush for 'richer' 'user interfaces' (UIs) and 'better' 'user experiences' (UXs) will get rid of this fantastically valuable feature.

>As it is, HTML is so simple it's tough to mess up the UI. With much more powerful client side software tools, it will be tough NOT to mess up the UI.

I agree with where your post is going, but unfortunately we've already made all those mistakes, already lost all the niceties of the web. Our stateless, linked-document viewer is already dead. HTML isn't dirt simple anymore. For years a "web-app" has already has all those undesirable properties. We've made the browser environment complex. The hardest to use applications I have these days are webapps. And when it became complex we didn't give ourselves any of the niceties of native applications, so they're even more of a mess than native ones.

1 comments

Sure, it's possible to write some really bad Web apps. E.g., at my bank, they keep changing their Web site so that once each few months I have to click and click and click to look for where they have moved the page to let me download the PDF of my bank statement. Their 'navigation' is NOT clear.

Yes, building a Web site can be as complicated as we please: I'm buiding one now, my first one, and I am surprised at how much there is to it. So far all the work is just routine, but in total there is a LOT to it. E.g., my main Web page where a user enters some data has 160,615 bytes of typing and may top 200,000 before the page is done. I see the page as 'simple', and I hope my users will, but not everything can be simple about 200,000 bytes of typing. Yes, at 50 characters per line, that would be 4000 lines or, at 50 lines per page, 80 pages printed out!

Still, compared with a 'native' application, in practice HTML heavily constrains what a programmer can do with a user interface. So, an HTML interface is constrained to be relatively simple.

My main point remains: In total, one billion Web users can use any of over 100 million Web sites right away. That's a BIGGIE.

In the Web site I'm developing, I'm going with Microsoft and Visual Basic .NET,.NET, ASP.NET, and ADO.NET. Yes, ASP.NET writes some client side JavaScript for me. Fine with me. But so far I have yet to write a single line of JavaScript and intend to keep it that way!

But if do a lot of client side programming in JavaScript or any more capable successor, then risk programmers having fewer constraints, user interfaces becoming more complicated or, just, unique to each Web site, ease of use of the Web for a billion users going into the toilet, and the Web growth being throttled.

For my Web site, the user interface is SIMPLE. Yes, for each little thing a user does, there is a 'post back' and a 'round trip' to my server. Sure, something native could be 'snappy'. But I'm taking the approach, KISS. And, sure, each round trip lets my Web site put up a different collection of ads! For my most complicated Web page, what my server sends is less than 200,000 bits, and that can go to a user and be displayed VERY quickly. So, my site can appear to be nicely responsive.

Some of what's going on deep inside my servers is complicated, but the user interface should be so simple that people who don't know English should be able to use an English language version of my site! I'm drooling over the fact that one billion Web users will find my site easy to use, if they want to use it!

Net, I recommend that we keep the HTML Web UI SIMPLE.