Hacker News Reader

Comment by rgbrenner | Hacker News Reader

We need a break. We need an opportunity to learn to the features we already have responsibly — without tools! Also, we need the time for a fundamental conversation about where we want to push the web forward to.

How about this.. YOU take a break. Stop trying to keep up with every little new thing that comes out. Wait a while.

And you'll get exactly what you want.

The tools that it turns out were a bad idea will die. And those that are good will thrive.

And you'll get more time to learn the actually useful ones... and you'll get to learn from the mistakes others made early on.

Yes, you'll be a bit behind.. but you're apparently already ok with that anyway.

View on HN

Do you know PPK and his work? He's been at the cutting edge of web-standards and implementations for at least 12 years if my memory serves me correctly.

>And you'll get exactly what you want. //

If he wants to avoid the web being badly negatively effected by short term views of current browser companies and standards bodies then he won't get what he wants by sticking his head in the sand and ignoring the direction he sees things going.

If this were the writing of a small time web-dev (like myself) then I think your comment would work; but I'm assuming PPK is coming from a position of experience that's given him an almost unique overview of the direction of browser and standards development vs. the historic "feel" and integrity of the web.

PPK is doing the equivalent of saying "let's stop and ask for directions [on our car journey]" and you're saying "no, let's just keep driving I'm sure we'll get to where we want to go".

He's up against it as, to my mind, cautious development doesn't serve the needs of corporations and so won't happen.

>"We’re pushing the web forward to emulate native more and more, but we can’t out-native native." (OP) //

I find it funny that web pages are trying to be native apps and many mobile apps are shipping when they're ostensibly just web pages.

tl;dr I think the OP has more to say, and that it's more important, than you're giving credit for.

> I find it funny that web pages are trying to be native apps and many mobile apps are shipping when they're ostensibly just web pages.

Which provides some insight into what's missing from the web. It's almost good enough for most companies. They just need a little something extra so that they can "own the experience." But soon the browsers will catch up and then websites will be able to own your experience, too.

Perhaps the choice lies outside of the actual functionality of the web itself but instead in the OS and browsers.

Consider someone who ships their iOS app that is basically just a web page instead of using a web page. For doing this, they get two benefits that are not really related to the web. One, they get an icon to tab from the home screen to launch their app, instead of going to Safari and then going to their webpage. Two, they get to avoid having to go through Safari, which one could speculate is something Apple was already wanting them to avoid as it allows Apple to create a better walled garden (not to say Apple is the only one who does this, I'm only pointing them out because I used iOS in my example).

How would a change/upgrade in web standards allow for the web app to compete with the iOS app housing a web app on these two fronts?

Just in case you're not aware, you can already make web apps in iOS have a icon on the home screen. See https://developer.apple.com/library/safari/documentation/App...

+1 thanks for that!

Does anyone have a link for something similar for Android phones?

https://developer.chrome.com/multidevice/android/installtoho...

HTM5 appcache to the rescue!

http://www.html5rocks.com/en/tutorials/appcache/beginner/

It's rad.

Rad is definitely not my experience.

I've spent A LOT of time trying to get my site's appcache functionality to the point where it's barely usable. Probably more time than all of its users would have spent downloading the resources it was supposed to cache. It has more gotchas than anything else I've ever experienced.

This is incredibly accurate: http://alistapart.com/article/application-cache-is-a-doucheb...

From a tech standpoint, yes. There are some pretty powerful interests that don't want to see the open web on mobile. Google and Apple get handsome cuts of all the revenue on their semi-closed platforms. Consumer demand may shift that, but I'm not holding my breath. The open web was an historical anomaly: historically the large information infrastructures have been nearly monopolized (telegraph, phone lines, cable/broadcast).

The web is an anomaly yes, but it has broader reach than any other platform in the history of mankind. Thinking that native apps will kill the web is to miss the forest for the trees. None of these proprietary platforms have the reach of the web. No computing device maker can release a credible device without web support. It doesn't matter how much money you have, you can't make your proprietary platform cross the chasm the web has crossed. Apple can't do it, even open-source Android can't do it, because Android is runtime, not a standard.

The common narrative of PC app -> Web app -> Mobile app is only superficially accurate in terms of where the tech hype was at different points. But in terms of long-term life cycles, mobile apps are much more like PC apps, and the web is something else completely different, which we've never seen before, and mark my words, it will not disappear or be superseded anytime soon.

the web is something else completely different, which we've never seen before, and mark my words, it will not disappear or be superseded anytime soon

Smalltalk environments?

That's the gist of it. The web is a file server protocol with a pseudo-Smalltalk coating.

We've seen hypertext systems in general many times before the web.

None that crossed the chasm. That's what makes the web special and unique, not the functionality.

The web ten years ago was indeed different when clean markup, separation of concerns, accessibility meant something. Nowadays it is just a mess, cannon fodder in the battle nobody asked for.

It "meant something" for a tiny fraction of web developers. The vast majority of developers in 2005 was probably either using Flash or creating something that only worked in IE (with its 85% usage share).

Yes, I totally miss the good ole' days of bitching about IE getting the CSS box model wrong, despite the fact that it was the better implementation and as soon as the standards gods deigned to bless us with 'border-box' everyone kind of pretended those threads on css-discuss never happened... Or endless bickering over the best unit to declare font-size in, because of course it made absolute sense to leave accessibility to site designers, not browser implementations... Or posturing over why 'float' was actually a valid layout concept for anything besides a block of paragraphs with images interspersed... Or the endless clearfix or image replacement hacks... Ahh yeah, the good ole' days...

Once again, what so special about mobile? Somehow I don't see webtech proponents rallying for wining the desktop or winning the smartwatches. This obsession with winning the mobile is plain stupid. Instead of wasting time implementing half-baked features which will never catch-up the native offerings and stuffing more crap into already multi-megabyte web pages how about doing some spring cleaning?

What if I don't want corporations to own my experiences? An information-driven web with a document model is robust and can work with many different user agents. An experience-driven web with an application model is very fragile and will only be available to sighted, hearing, Mac-using people running a big 4 browser.

Who needs flash when we can have 15 competing application frameworks for the web that all just abuse the canvas as their medium, so we aren't even authoring HTML/CSS anymore?

Honest question: is abusing canvas really becoming prevalent? The only web app I've seen doing this is flipboard.

Prevalent? I don't know. I do think it's just a matter of time before some companies leverage this by providing a super simple web page developer tool a la Frontpage Extensions.

Photography studio webpage that just wants a carousel and music playing? Check.

Small companies that freak out about people stealing their inventory list? Check.

Vendor lock in for the poor souls that fall for this? CHECK.

Hmmm, maybe I'm naive, but I really don't see anything to suggest that things are headed this direction.

yeah I don't think that would be crawlable and we want seo

Then you're SOL, because web-delivered applications that own the experience will happen. Hopefully someone would come up with a better user-respecting user agent by then.

Funnily, iOS offers much better accessibility support than web. And I'd argue that many more apps use it (also Apple recently promoted apps with good accessibility support) compared to modern "web apps".

I really don't want them to "own the experience." I want their brochures to stay nicely sandboxed in a browser where they don't invade my computer and try to tell me what I can do with it.

Brochures are documents, nobody has a problem with putting documents on the web. Also, mobile apps are sandboxed already on all major platforms.

Right, I meant it as something of an insult. I'm fine with documents on the web. I'm fine with interactive documents on the web. I'm not fine with "web apps" that try to jump out of the browser, opening windows, redefining control-key sequences, breaking bookmarks, "open in new tab", and the back button, and otherwise interfering with my ability to control my own experience on the web.

No they won't, because it would kill the web. That little bit is ownership: branding and control. There's no Adblock for their app. Their app isn't called Firefox it's Company Name. There's no dev tool for the app, so less chance to find out all the insecure ways it siphons my data. They control updates, so their ActiveX-style monstrosities are always going to be displayed the same. Get the idea?

The fact that PPK did a lot of good work on web, doesnt mean this article is good. Any genius can create crapwork. So did albert einstein. I once saw a presentation from PPK where he proposed JSON over SMS....(http://quirksmode.org/presentations/Spring2012/bigm.pdf) IMHO that presentation was technically not very strong.

But the case that he is making in this post is strong.

>I once saw a presentation from PPK where he proposed JSON over SMS.

And that's bad because? Given some use cases it could be a very handy and pragmatic re-use of available resources and protocols.

because SMS has inherent costs in some countries, because SMSs are tiny (I'm pretty sure his example json structure was larger than a SMS max size even), there is already a mechanism in place (to see all SMSes), which would have to be hijacked (to not display what would be practically garbage to the end user)

push notifications already existed 3 years as a thing before this talk

Whatsapp, twitter, etc, all existed before this talk as mobile services (and twitter via a SMS interface, which is the far more reasonable way of using SMS uniformly across all phones)

It was a talk 3 years too late, data plans already existed, push services already existed, implementing such a thing via SMS would only lead a company to get ~6 months max use, wouldn't be as easy as other methods (receiving a push / making a web request, vs receiving a possibly fragmented SMS, and then having multiplatform hiding of this message), etc etc etc. I personally have to wonder if the talk was comedic (the part about how app stores make it impossible for people to find your app, makes me wonder this as well)

The post is neither good or bad. You just happen to disagree with the author.

I for one have been bitching (my colleagues know all about it) about the state of affairs in web dev for about year, and so far most people tend to agree. And my current project (mostly heavy Javascript) just reinforces that view, it's a total mess for little real gain.

> PPK is doing the equivalent of saying "let's stop and ask for directions [on our car journey]" and you're saying "no, let's just keep driving I'm sure we'll get to where we want to go".

Just because one person is lost doesn't mean everyone else in the vehicle is. Those who know where they are going don't need to stop and ask for directions. Don't force them to.

You have a valid point, not everyone is lost but obviously everyone seems to be digging in the same ship just for the sake of it. If you try to understand more of what OP is trying to say, then you will know that there are more problems created than solution.

It's getting more difficult for beginners to catch up or even were to start from (see lots of those questions on Quora), perhaps we need to reexamine things rather than building 4million cars a day only to realize we have global warming.

How did we go from Javascript to global warming?

Holding back technology so others can catch up is foolish. Where would we be if we followed that philosophy. We have long passed the ability of the human mind (at least unaugmented) to keep up with technology.

Sure, there are problems for some. But they are insignificant problems for others. I'm generally of the opinion that you should give people the freedom to choose rather than forcing things on them that are against their interest.

I'm very familiar with PPK. I lifted my first 'getElementsByClassName' function directly from his site well over a decade ago. That doesn't mean that he hasn't descended into troll-level talking head status, generating controversy to drum up speaking appearances. Plus, we have MDN and caniuse.com now - he's irrelevant.

This is the part that feels the most misguided to me:

> a fundamental conversation about where we want to push the web forward to.

There's no such thing as a "conversation" between the billions of people with a stake in this. Or even the few million people building websites and web apps. Or even the few thousand people building web browsers. Attempting to have that conversation just means open-ended delay. There will never be a clear consensus on where we want to push the web forward to. And that's OK.

"Attempting to have that conversation just means open-ended delay."

Isn't that the point? To slow this down because perhaps the people driving "innovation" are insulated from its disruptive effects?

> There's no such thing as a "conversation" between the billions of people with a stake in this.

Well, not exactly. That's how you wind up getting diversity of fields.

People have different interests and different visions of the future. People understand computation differently. People approach the same problem in different ways. Through conversation and code, the web is weaved together.

My thought is this. Put up or shut up. Why waste your time under a forum about a developer who wants more stable, secure software? Surely this view provides some benefit to the community, lest we prefer languages that compute incorrectly with regularity and a proliferation of vulnerabilities across every domain that has been coupled with technology.

But people are conversing about it in browser dev groups and in standards meetings (WAI, WHATWG and whatever) and such; they're just doing it with a focus to their own ends rather than the ends of the more general user population of the web.

As it should be, those who do the work get to make the decisions, that's how it works. People work for their own self interest, not for the benefit of the "general user population".

>People work for their own self interest //

Altruism; not exclusively, not always, not all people work only for their own benefit.

Many, I warrant, consider that something as game-changing and all pervading as the web (and internet in general) should be tailored as much as we're able to the greater good of all people. Others want to make it illegal to collect rain for drinking in drought zones so they can get a better financial profit selling bottled water. And there's a whole scale in-between of course.

But the web and the Internet are not things themselves, those are merely abstract words that describe a collection of privately owned computers doing things their owners deem in their self interest. Anyone who talks about what the Web should be doesn't understand what the Web is nor what decentralized means. No one gets to say what it is, it simply is what those who build it make it.

By the way, one of the best websites I know, c2.com (I don't know anything about this consulting company, but these pages constantly come up in search results and offer best advice possible), manages to deliver the best content with HTMLs that mostly can be read in Mosaic and Lynx.

That's the original Wiki, by Ward Cunningham. He invented it. Currently read only, unfortunately, due to a hack last year.

http://c2.com/cgi/wiki?WikiWikiWeb

Yeah, and now Ward's killing it in favour of some Web 2.0 thing I can't even begin to understand how to use.

Perhaps the most Web 1.0 place on the Internet, which I mean as a compliment. I don't quite get the revision/comment setup, but it's great.

Another proof that this whole web debate isn't going anywhere useful. Lot's of old places are full of amazing content. Maybe restricted communications channels allows for smarter conversations ? You have to tailor and curate the ideas. Mailing lists for instance are still used by real developers everywhere, IRC. Add a few blogs and old boards and you get 80%.

This works for the latest JavaScript framework, but is a lot more problematic when it comes to jamming fads into the browser: we have to support them, and work around them for a long long time.

I do this. I don't even really think about anything new until others have put it through a shakedown for at least a year.

Choose your tools and frameworks judiciously, learn them well, and you will be much better off (and less stressed) than the folks who are continually chasing the latest thing.

> The tools that it turns out were a bad idea will die. And those that are good will thrive.

We saw that happen with WebSQL vs IndexedDB. A well-designed API (with a syntax every decent webdev knows) vs a bullshit spec (ohai callback hell FOR DOING A SIMPLE FUCKING SORT AND GROUP), and the bullshit won.

All because Microsoft wouldn't break down and embed SQLite into their browser like everyone else did for WebSQL. It's actually really disappointing.

IndexedDB could be built on top of WebSQL as a shim... you can't really do the reverse so easily. It's really disappointing... WebSQL/SQLite with a template string builder interface would be amazing. (I know it's an ES6 thing).

I will say, that I do want what's on deck for ES6/7 (2015/2016) to make it into the browsers... async/await is such a useful feature.

Hmm... would it be possible, using Promises, to create a sorta-shim, you give it a SQL query and a callback function.

The shim does asynchronously all the stuff a DB engine does (most people are going to use "SELECT cola,colb,colc FROM x WHERE foo=bar and baz=quux ORDER BY cola ASC GROUP BY colb" and nothing more complex anyway), then tracks all the stuff it needs to do in its own promise tracker. Once all is done, it assembles the returned row(s), stores them and calls the callback.

The biggest problem I see is locking as all the crap is async so you'd need some sort of locking and query ordering to maintain data consistency.

If you don't really need true locking pessimism it's more possible... There are actual SQL engines in JS though.

Using a single queue to run queries through would be relatively easy to do... a stage 1 analysis of what collections you need to query could then push the query into one of several queues for pipeline requests.

It would be interesting, but I don't mind IndexDB (or localStorage for that matter) enough to really bother with it.

Because Microsoft and Mozilla wouldn't break down - and Mozilla already shipped SQLite.

Sorry, I had thought Mozilla had WebSQL with SQLite... I know chrome/safari supported it at least.. I thought MS was the main holdout there. It looks like there's a Firefox plugin for it though.

It's not that simple.

1. The spec died, because it didn't get two independent implementations.

Everyone merely wrapped sqlite, which meant sites could rely on being bug-compatible with all the sqlite weirdnesses (e.g. column type "floating point" parses as integer column type), and making any future upgrades or fixes of sqlite a Web-wide version of pain of upgrading IE6 used for an intranet site.

2. IndexedDB API is a pain to use, because it's designed to be used directly. In the spirit of extensible web manifesto, it's a low-level primitive for JS libraries to build convenient higher-level abstractions on top of.

It's like an "assembly" of storage. It's supposed to enable building higher-level databases on top, so you can have SQL or NoSQL with whatever dialect you want, without burdening the platform with it. Use Dexie, localForage, ydn or such.

While it is probably true that we "can't out-native native" the argument is irrelevant if you consider other more important factors.

The approval process is burdensome and discriminatory if you want to release an app that competes with Apple or goes against one of their policies.

For developers that want to create great mobile user interfaces and Apple won't approve the app, where does that leave us? No user experience or a sub-optimal user experience. If we do what PPK is proposing that leaves us with poor user experiences and maybe no user experience if we need a feature that is only available on native.

Having a web platform that can compete with native apps mitigates the problems and abuses common with companies that have monopolies. If they have competition they can't screw over their developers and user.

30% is an onerous tax. It's one thing if that is a marketing or referral fee. But if a developer is creating an app to use with their own platform / service they are most likely going to provide a download link from their site. They don't need any promotion or directory. Apple isn't providing any value. They are creating an artificial barrier and blocking other companies from serving their users just so they can get a cut of the action.

I've been using ES6 functionality like "yield" in my backend node.js code and am loving it. I would love to have that ability in the browser without having to go through a transpiler.

I want the web to keep pushing forward so that I can deliver better user experiences.

The argument that we need time to catch up and learn the technology seems ridiculous to me considering that the alternative is learning 3 platforms (web, iOS, Android) vs just 1 platform (web). A lot of developers don't want to have to develop for 3 different platforms.

If you can't keep up with all the technologies then become a monk and leave the technology world behind.

Nobody has been able to keep up with all the latest technology trends. Deal with it. Those that want to deliver better user experiences will invest the time to learn the new technologies.

Don't hold back progress just because you have a defeatist, why me, it's not fair, slow down guys, I can't keep up attitude.

>How about this.. YOU take a break. Stop trying to keep up with every little new thing that comes out. Wait a while. And you'll get exactly what you want. The tools that it turns out were a bad idea will die. And those that are good will thrive.

Yeah, only hasn't ever happened. We still suffer from BS tools and ideas from late nineties, and we're only mostly piling stuff on top of it (some good and loads of crap).

Imagine that you and your friend are hiking together. After a while your friend says: you know what, I think we are going in the wrong direction. You tell him something similar to your comment. And yes, he waits. And while he waits you get deep into the swamp. The only think you learn is maybe how to hike in a swamp. Yes he left behind. But being left behind while others run deep into the swamp is not the worst that could happen. Alas, everyone lost some time.

This seems like just a bunch of excuses to keep breaking the web.

Reply on news.ycombinator.com