41 ms·

Stop pushing the web forward

• n0mad01 11y ago
  some truth has been spoken - broken features should be fixed first - then we'll look again towards the future.
• sanxiyn 11y ago
  For comparison, see "Python Language Moratorium". I think its outcome was positive. https://www.python.org/dev/peps/pep-3003/ https://www.python.org/dev/peps/pep-3003/
  • sylvinus 11y ago
    Was it really? I'd like to see proof that it actually helped Python 3's adoption. Wouldn't new features from 3.5 like async/await have given people more incentives to switch had they been released earlier? (they would have for me)
  • drivingmenuts 11y ago
    Python is a language with one official supplier and many customers. Most of the other Pythons base their functionality in the official Python and alter the underlying code to suit the platform. Browsers are supplied by at least three main sources and several smaller sources, each trying to convince everyone that theirs is the One True Browser by pushing forward at breakneck speed. There is never going to be total agreement (or even sanity) as long as that is the case. It's a mixed blessing, IMO.
• charlesray 11y ago
  >This sounds cool, but why would we want to do that? We’ve done without for years. More importantly, end users have done without for years, and are quite used to a slight delay when they load another page. People were used to dying of typhoid, too.
  • terrywilcox 11y ago
    Quite a valid comparison. The damage caused by the lack of Navigation Transitions in web browsers has made the news repeatedly for decades. My great grandfather died in the hospital after he was crushed by a non-animated change to a different webpage.
• skwosh 11y ago
  As a corollary I'd like to say: stop pushing JavaScript forward. There seems to be a lot of focus on providing syntactic sugar for things that already exist (like classes, decorators, etc) at the expense of flexibility and composability (executable class bodies, @foo vs normal function application, etc). What JavaScript needs much more IMO is a (better) stdlib, with more datatypes and procedures than currently available (including big numbers, the various flavours of trees, better support for equality and comparison, etc).
  • bhousel 11y ago
    >What JavaScript needs much more IMO is a (better) stdlib, with more datatypes and procedures than currently available (including big numbers, the various flavours of trees, etc). Isn't that "pushing JavaScript forward?"
    • adrusi 11y ago
      Maybe what skwosh means is a moratorium on new features in javascript so that we can refocus on the features that are useful, and actually improve rather than complect the language.
      • skwosh 11y ago
        Thanks, that's what I mean. My feeling is that some of the syntactic extensions to the language are piecemeal and don't reflect the full expressivity of JavaScript.
    • angersock 11y ago
      It's slightly different. The addition of sets and symbols, for example, did little to change what an existing codebase looked like. Similarly, adding explicit trees, binums, and so on won't really change much. The improvements going on right now, though, seem mainly concerned with syntactical sugar and extra syntax. The problem (and I'm in a minority here, I think) is that this creep and bloat takes a quirky language that fits into one's head and instead starts making it a rat's nest of special-cases and odd interactions. This is the sort of thing that caused C++ so much trouble. Once they add annotations and shared state and threading (and that's coming), the party will be over and the earth salted.
• bshimmin 11y ago
  This was the first I'd heard of "Navigation Transitions" (perhaps I don't read the right mailing lists), and ppk's right - this seems like an absolutely crazy feature to add.
  • callum85 11y ago
    What about the idea turns you off immediately?
    • bshimmin 11y ago
      Two things: 1) it requires an extra stylesheet (from what I can make out, at least); 2) you can already achieve this with JavaScript, if you really want it (which is, itself, debatable), so why add extra cruft into the browser? Also, from the page ppk links to: <link rel="transition-enter" duration="0.25s" href="URI" /> This makes absolutely no sense, though perhaps it has a place amongst the wealth of gibberish we've seen stuck between <head> tags over the years - <meta http-equiv="pragma">, anyone?
• ixtli 11y ago
  > But why do web developers want navigation transitions? In order to emulate native apps, of course. If we're doing unpopular opinion time, I think this is the real issue that no one wants to talk about. I'm all for whatever feature development the community can standardize. Apple, google, mozilla, and etc. all have smart people working for them and when they cooperate things seem to work out fine. The problem is trying to achieve the feel of native applications in a _non_ native application. Browsers should do one thing well, but that one thing has no real business being duplication of mathematica, quake, or visual studio. It's always interesting to see a Show HN where someone cleverly gets an approximation of one or another of those things running in the browser, but come on. Making the browser the operating system is simply going to push the same old incompatibility problems into the browser. It's not going to solve them.
  • tutuca 11y ago
    If you read further they link to a previous post that covers just that: http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html http://www.quirksmode.org/blog/archives/2015/05/web_vs_nativ...
  • rtpg 11y ago
    I'm sorry but how would making browsers the operating system cause the incompatability problems to reappear? I think this is massively ignoring the realities: - there's almost no native-feeling cross-platform UI library for native apps at the moment - There's a standard for most things happening in a browser, which means that things look pixel-perfectly the same on a huge amount of browsers. Differences among current browsers are more among performance and experimental features So currently, if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_. The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.
    • pikzen 11y ago
• anp 11y ago
  I've seen this sentiment a few times: "don't try to replicate native apps in the browser." Which makes sense from the standpoint that the browser is just getting ridiculous, like a mini-OS unto itself. However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen. It's the same reason that desktop Java was in vogue for a little while: you only have to write one UI, and you can run it from a HTTP connection with almost no local permissions. Of course, this was (and still is) a security nightmare, but browsers now do a pretty good job of sandboxing individual code blobs, and also do a pretty good job of abstracting away the native UI. Web apps also provide low or zero installation overhead (low friction to getting a user onboarded/working/monetized/whatever). It would be nice to see some progressive enhancement folks address how to resolve these pain points on the native side, rather than just saying web shouldn't be like native.
  • ebauch 11y ago
    Totally agree. Just look at the mess with mobile OS. It is nearly impossible to develop a native app yourself without excluding half of the world population. In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along.
    • AlexandrB 11y ago
      > In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along. As primarily a user of mobile apps I would mind. A web app experience is at the mercy of the network I happen to be connected to. In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.
      • JoshTriplett 11y ago
        > A web app experience is at the mercy of the network I happen to be connected to. That's one of many things that web apps have been fixing. It's entirely possible to write an offline-capable web app. > In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS. They do, however, look like web apps everywhere, and if you primarily use web apps, you'll feel right at home.
• deleted 11y ago
  [deleted]
• RubyPinch 11y ago
  slinging around "web trying to be native is bad" in the way the author does is such a thoughtless argument: just because something exists in native land (a land of a lot of well paid researchers and designers, etc etc), doesn't make the idea bad for everywhere else. Maybe the idea is just a plainly good design decision? (I mean, do you have fond thoughts of the entire page flashing white, then pieces of the page bouncing around the screen as they try to position themselves based on content that hasn't loaded yet?)
  • JustSomeNobody 11y ago
    "(I mean, do you have fond thoughts of the entire page flashing white, then pieces of the page bouncing around the screen as they try to position themselves based on content that hasn't loaded yet?)" You mean like it does now?
    • RubyPinch 11y ago
      yes, which is why "imitating native", aka not reloading the entire page, is seen a lot more on sites like facebook and twitter (the ui stays the same as the main page reloads), this is done to provide a more comfortable experience, sans screen flashing rave party navigation transitions (more of this horrible ugly "native" stuff) is standardizing a mechanism for this
• cognivore 11y ago
  "However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen." Does it? I used to think that. Until every medium-complexity or worse web project I've worked on took forever as we went through all the different browsers and OS's and now mobile and tablets and responsive and OMG just give me a decent native app tool now please. Browsers absolutely suck at UI beyond their original intended domain.
  • mobiuscog 11y ago
    It certainly allows (some) organisations to 'believe' this. Unfortunately.
    • tonyarkles 11y ago
      Ahhh, I'm with you, but not with you. There's a lot of Line of Business apps that can be written really easily as webapps. Right now my default toolkit for doing those is: Rails, Angular, Foundation. These are often pretty much just slightly-interactive forms and reports, and fit reasonably well within the browser model. These aren't profit-centric apps, these are cost-reduction apps. One of the best parts about web apps in this context is that they reduce the deployment and management costs. You don't have to worry about supporting legacy versions, nor about deploying new versions of the apps to every machine in your organization. They don't have to be perfect or beautiful, they just have to save more time and money than they cost to build and maintain.
  • dikaiosune 11y ago
    Was this in reply to my top-level comment? Looks like this ended up a sibling instead. In reply to your comment: Perhaps, and I lack the experience and evidence to contradict you. I work solo on small to mid size projects that are mostly back-end. But I am fairly confident that with the large number of mid+ size web app projects we would be seeing a migration back to more native apps if the overhead is actually greater than maintaining multiple native apps. It's not like every company in the world is incapable of independently assessing their needs. And bandwagons will form when independently-minded companies change their processes. So why aren't we seeing a mass exodus from complex web apps? And why are many orgs using native wrappers around these supposedly terrible web apps to produce a pseudo-native app? EDIT: Also, how would you address how much easier it is to try out a web app without having to install it vs. finding, downloading, installing and running a native/mobile app?
• rythie 11y ago
  ...meanwhile we still have flash video because HTML5 isn't good enough to replace it yet.
• mkozlows 11y ago
  I've gotta say, I'm somewhat sympathetic to the idea that we'd be better served by a period of focusing on stability and performance over new features... but talking about the IE6 stagnation era as a good thing? Yeah, no, that was awful, and if you're holding it up approvingly, well, now I officially disagree with you.
  • scholia 11y ago
    The IE6 era (2001 to 2005 or 2006) was a period of great creativity, and it was when a lot of dominant web properties became established. Examples include Wikipedia, LinkedIn, Second Life, The Pirate Bay, MySpace, Orkut, Facebook, Gmail, Flickr, OpenSreetMap, YouTube, MegaUpload, Pandora and Twitter. Web 2.0 became popular during that era (2004 onwards). That "stagnation" compares rather well with much of the flashy, transient rubbish being launched nowadays. Also, when it came out, IE6 was the most standards-compliant browser and generally performed better than its main rivals.
• deleted 11y ago
  [deleted]
• ForHackernews 11y ago
  > Interestingly, Microsoft added a similar feature to IE4, and deprecated it as of IE9. The idea didn’t catch on because back then nobody wanted to emulate native apps (which didn’t exist), and therefore nobody particularly cared if the users had to briefly wait for the next page. > native apps (which didn’t exist) Does this writer believe that nobody installed software on their computers before the iOS app store opened in 2008?
  • scholia 11y ago
    The usual meaning is "native apps" for smartphones, as opposed to traditional programs like PhotoShop and AutoCAD. It's a broadbrush description but almost everybody gets it. Would you like to offer a simpler, shorter and more accurate way of making this distinction?
    • ForHackernews 11y ago
      I think it's a silly distinction to make. Native applications (meaning software running on a computer, outside a browser sandbox) have always offered a smoother, more comprehensive user experience. That doesn't mean users get no value from the web, or that they're so spoiled by fast transitions in Microsoft Word that they won't want to use a website.
      • scholia 11y ago
        I agree, but that's not the point. The point is that some -- perhaps many -- people want to distinguish between smartphone apps and traditional programs, and that's one way to do it. It would be nice if there was a better way, but I don't know of one. Incidentally, it's a distinction that people also make between "universal apps" (written for Windows Runtime) and desktop programs (written to the Win32 API) even when they do the same job on the same Windows 8 or Windows 10 PC.
        • bztzt 11y ago
          The meaningful difference is whether there are isolation and distribution/update mechanisms so that users can install and maintain apps with less risk and hassle. This doesn't have much to do with (in-app) UI per se, though.
• rgbrenner 11y ago
  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.
  • ams6110 11y ago
    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.
  • mrspeaker 11y ago
    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.
    • deleted 11y ago
      [deleted]
      • hueving 11y ago
        Lots more than browser devs get hit by this. Crawler developers, screen-reader devs, browser plugin devs, mobile app devs, etc.
  • bjt 11y ago
    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.
• IanDrake 11y ago
  In a way, I see what he means. Let's take a breather to let all the major browsers support the existing standards before we give them more draft specs to chase.
• Eric_WVGG 11y ago
  “Everybody will have a favourite upcoming feature that would be hit by the moratorium — mine is offline capabilities.” Mine would be next-generation image handling — <picture> tags* and some sort of alpha-blendable lossy format. I work for a lot of artists and designers, these guys want fast, retina full-screen responsive images, and I’m not sure that it’s an unreasonable expectation, but I’ve got enough technological hoops to jump through to recall the days of “Netscape Now!” and “IE 5” badges. * don‘t talk to me about the unholy abortion that is srcset
  • jacquesm 11y ago
    > I work for a lot of artists and designers, these guys want fast, retina full-screen responsive images, and I’m not sure that it’s an unreasonable expectation, but I’ve got enough technological hoops to jump through to recall the days of “Netscape Now!” and “IE 5” badges. Do the users want those too?
    • Eric_WVGG 11y ago
      Do users want cellphones with 64bit CPUs, 1gb DDR4 RAM and an SSD, or a phone that turns on instantly and has near perfect responsiveness? When I get the visuals dialed in a way that is quick and responsive, yes, the users seem quite receptive. I could do a better job for them with better tools at my disposal.
    • Eric_WVGG 11y ago
      sure wish someone had explained why they disagreed instead of downvoting me :\
  • pfooti 11y ago
    You know what I want? I want a tag that I can use like <img> but more flexibly- I want to manage cache and authentication on images displayed in-browser, and the fact that I basically have to use URL or Cookie auth for image embeds is ridiculous. My entire API uses tokens, except for when it deals with image resources (and those images need to be protected to only display in the correct place, because they're not pictures of cats, but Highly Sensitive pictures of Important Cats).
• swalsh 11y ago
  The web is an ecosystem, browsers are species. They create new mutations in a new attempt to thrive. The definition for what it means to thrive is always the same. To replicate oneself the most. That means the largest user adoption. If performance is what users judge by, then browsers will adopt to it. If transitions are what users what, than browsers will adopt. IE had trouble adopting, it had the wrong balance of features. That's why it started to go extinct. You can't DESIGN an ecosystem. You can't tell an ecosystem to stop churning. It just keeps going. Timing also matters. If a fish evolves a hand, does that make a better fish? Maybe not, but if the fish starts breathing, and living out of water... maybe those hands would be pretty useful.
• drb311 11y ago
  Damn that page loads fast.
• eleitl 11y ago
  Much too late. If something is not plain text or PDF/A it has already bitrotted away, or is well on its way. The Web is an ephemeral enterprise.That's why everything relevant has a DOI and not an URI.
• alricb 11y ago
  New features also mean new security bugs. A complete freeze might not be optimal, but the "security cost" of new features could be given more weight when deciding to add something to browsers.
• bcg1 11y ago
  PPK, I'm sorry but you are midair, directly above the shark on this. Its not too late to change course though. We realize you are a mobile consultant, and standardizing many features in a cross platform is a threat to you and your client base. But getting on your soap box and telling people to not add features to browsers is unhelpful and myopic. Not everyone uses your stupid mobile platforms. Some people in the world don't even have a phone at all. But they might be able to use a browser once in a while. Do they not deserve features just because you have decided that it would be too difficult to implement in the browser, and will "never be as good as native" or however you put it. Your failure to see how things could be implemented faster/better/cheaper does not preclude others from actually getting things done. I actually agree with many of the points that you make, but seriously... try to see the forest for the trees and take a look at what you're asking of people, and ask yourself why you are doing that.
  • kabdib 11y ago
    I've spent the last two years doing "full stack" [yeah, those words, sorry . . . but going from bare metal to C++ to PHP/JavaScript to frobbing routers all on the same day probably qualifies], coming from a background of C/C++ driver and native code development for 30 years. What I see is an immature community that cannot make up its mind. I see fads, I see awful tools, and even more awful tools that try to fix the awful tools. I see standards committees that pump out unimplementable garbage and I see device manufacturers who think they are good at writing software (and they are not). I see very bad, widespread and unpatchable security holes. I read, every week, about the latest fad thing that will fix all your problems, just install a list of 30 packages and suffer per-page downloads that are larger than the native apps this mess is trying, badly, to replace. I guess this will all shake out. But in the mean time, I am shaking my head.
    • bcg1 11y ago
      This is the problem with what PPK is suggesting. The Firefox and Chrome developers are mostly certainly professional developers who are well qualified to create a standardized cross browser feature set that will obviate the need for the cruft. Only recently have we started to emerge from the Silverlight-Flash-JavaApplet-ActiveX-webish ghetto that we were mired in for years as Microsoft refused to add new standard features to IE. His suggestion is essentially to return to that paradigm. He should know better... he built a site called 'quirksmode' after all...
• robbrown451 11y ago
  "Native apps will always be much better at native than a browser. Instead, we should focus on the web’s strengths: simplicity, URLs and reach." For me, the web's main strength is that you have to write your application only once. I don't have to think about redesigning the UI because "that's not the iOS way" or "that's not the Android way." I don't have switch between different languages and write the same damn thing one more time. I don't have to hire a whole team to have an idea see the light of day and be accessible to the great majority of people. And if my idea is a little idea, I don't have to struggle so much to get people to check it out, given that installing an app is a much bigger barrier than clicking a link. I understand that if I want to be on the bleeding edge, and I want it to be optimal whether it runs on a phone, a tablet, or a computer-proper, browser dev can be challenging. But I don't always have to be on the bleeding edge. Still, it's nice to know that browsers are becoming more and more capable, so there isn't quite as huge a chasm between native apps and something that runs in a browser. That's an artificial distinction.
  • bcheung 11y ago
    Agreed. I for one do not want to be forced to develop on 3 platforms just to provide a decent user experience. Take all that effort and focus it in one place to create a truly great experience.
  • jay_kyburz 11y ago
    Also Security. Installing an app (even from an official store) is just too risky. Even a non-malicious app can significantly undermine your machines performance. When I close a browser tab, the web app is gone!
• agentultra 11y ago
  The cool thing about many of these features is that I can push out some code that I can share with a hyperlink and other people can run it without installing anything other than a browser. The authoring experience is still terrible. And the user experience still requires hopping over the secret, invisible wall into developer-tools land... but the potential is there. If you're savvy enough to open your web console and view source you can mess around with some code I wrote to demonstrate some fundamental procedural algorithms[0]. I chose Javascript and <canvas> because everyone has a Javascript interpreter and most browsers today support <canvas>. If I had chosen to demonstrate these algorithms in Python, for example, I'd have to expect my reader to download and install a Python interpreter for their system, download or copy/paste my examples, and load them into their REPL before they could start playing around. The browser experience requires fewer steps. A moratorium would be a welcome change of pace, IMO. It'd be nice to close the gap between the user and the developer and between document, code, and media. It'd be nice if authoring tools for these environments could catch up with the available features. On the other side of the coin the proposed common byte-code format is really exciting and practical for all sorts of reasons -- in the case of my aforementioned blog post I think there are better languages to teach with than Javascript and having that language be available as a first-class citizen in any web document would be a boon. I think some features would still be worth pursuing in favor of others. [0] http://agentultra.com/2015/06/24/introduction-to-procedural-algorithms/ http://agentultra.com/2015/06/24/introduction-to-procedural-...
  • romaniv 11y ago
    The cool thing about many of these features is that I can push out some code that I can share with a hyperlink and other people can run it without installing anything other than a browser. What you describe is a hack for lacking isolation/security/permissions/package management in the operating system. Seriously, if there was a sensible way of isolating apps and handling dependencies, it would be perfectly sensible to implement a lot of the current web "apps" as real applications.
    • agentultra 11y ago
      What I was attempting to describe was a document format the freely mixes code, documentation, and interactive media. The present set of features in the browser allows for a very fluid mixing of these elements but the authoring tools and user experience are lacking in most browsers. I can share similar documents via org-babel, iPython notebooks, or Matlab notebooks, etc... but each requires the user to be accustomed with those applications to install them, fetch my code from a URL, load it into their environment, etc. With the present browser ecosystem they can fetch everything as a single document and run the interactive examples and modify code on the fly... if they're willing to hop over the developer-tools wall.
• MrDosu 11y ago
  The only reason web applications are such a big thing is discovery. It is much easier to get someone to your page than it is to get him to install an executable. What we need is better app marketplaces with OS integration.
• vbezhenar 11y ago
  I don't think web moved forward. There are some fun features, but the only thing I really see in last years is HTML video replacing Flash. Otherwise it's the same web as it was 10 years ago.
  • rocky1138 11y ago
    From a technology standpoint I agree with you, except that images have gotten larger in file size. Socially, we've lost the "anything is possible" vibe that the early web had, thanks to oppressive governments and spying.
    • immibis 11y ago
      > Socially, we've lost the "anything is possible" vibe that the early web had, thanks to oppressive governments and spying. I'm not sure those two things have anything to do with each other.
• return0 11y ago
  Things like webRTC are the real push forward. It turns the browser to an operating system that can do everything a native app can do. I agree about the attempts to mimic "cool" animations from iphones - that's just cheap.
• deleted 11y ago
  [deleted]
• raintrees 11y ago
  This viewpoint reminds me of an Attorney's, who used to be a City Attorney: He felt that for every law passed, two should be struck from the books. Or taxes: I have heard it said a politician rarely finds a tax they want repealed. Wouldn't focusing on core web infrastructure for a period of time encourage addressing shortcomings, like the current state of security (and sometimes lack thereof)?
• Johnny555 11y ago
  Native apps will always be much better at native than a browser That may be true but I don't want to install dozens of applications, I like being able to run apps in my browser. Google Docs is great... 99% of the functionality i could ever use in an office app, and no need to install software (if it even runs on my platform). And I absolutely hate browsing the web on my phone to have every site pop up a "hey, try our mobile app, its soooo much better" message that gets in my way.
• 0xFFC 11y ago
  I think the answer to all question/problem get mentioned in comments is WebOS or specifically ChromeOS.you have web cross platform app,without huge cost of browser on top of os(so vendor can optimize the software stack very well).only problem with ChromeOS is non organized native app development.which could be solved by WebAsm.
• jscottmiller 11y ago
  > Instead, we should focus on the web’s strengths: simplicity, URLs and reach. How does new browser feature X prevent a developer from doing any of these things? > Being forced to work around IE6’s issues required quite a bit of creativity, and although not every solution stood the test of time (most libraries and frameworks from that era, for instance), it still made the creative juices flow. 'Tools' are bad except when they are used to work around stagnant browsers, I guess?
  • adrusi 11y ago
    Both of your points are right, but I'd like to point out that regarding: How does new browser feature X prevent a developer from doing any of these things? A moratorium on new features probably wouldn't help, but the reality is that web developers are focusing on new shiny browser features that allow for deeper native integration, rather than on the core elements of the web that work and carry greater usability gains, like offline support.
    • jscottmiller 11y ago
      That's a good point. I can see a progression like: developer finds new feature X that solves problem Y, developer finds that feature X is only supported by 20% of customer browsers, developer adds polyfill in XXX kB, buggy javascript library with other performance-related side-effects. Maybe the issue is just educating web developers about what's available, and the non-obvious side-effects using feature X. Here's what I'd like to see: organize a site like caniuse not by feature, but by tiers of support in the entire population of installed browsers. Something like: Supported by 99.99% of user-agents: image tags, ... Supported by 95% of user-agents: XHR, ... (I'm making those numbers up).
  • romaniv 11y ago
    For example, a lot of the problems that could be easily solved via declarative HTML tags are being solved via low-level JavaScript APIs. Not to mention that the web sets its own expectations. If everyone uses stupid modal popups, your clients will expect you to use stupid modal popups.
• cwyers 11y ago
  I think this is the key: > The moratorium would hit Chrome much harder than it would the other browsers, since it’s Google that is proposing most of the new features nowadays. That may not be entirely fair, but it’s an unavoidable consequence of Chrome’s current position as the top browser — not only in market share, but also in supported features. Also, the fact that Google’s documentation ranges from lousy to non-existent doesn’t help its case. I think the title and a lot of the rhetoric is misleading, really. It's not so much "stop pushing the web forward" as it is "stop letting Google decide where forward is and leaving everyone else to either ratify it or be irrelevant." And, uh, good luck with that. I mean it. I would love to see that happen, but I don't see how to get there.
  • aquilaFiera 11y ago
    I wouldn't categorize Google as the leader anymore. Mozilla and Microsoft have caught up and are as much leading the charge as Google is. Four years ago I would have agreed but four years ago we needed Google to push the browser forward.
    • azatris 11y ago
      Do you have any growth statistics as reference?
    • huskyr 11y ago
      The stats seem to disagree (1): Chrome has risen from a global usage share of 20% in 2011 to almost 50% today. Compare that to Firefox (2011: 28%, now: 16%) and IE (2011: 44%, now: 18%). (1): http://gs.statcounter.com/#browser-ww-monthly-201106-201506 http://gs.statcounter.com/#browser-ww-monthly-201106-201506
      • glandium 11y ago
        I'm pretty sure he's talking about W3C/WHATWG activity, not market share.
  • immibis 11y ago
    IE used to be the top browser, but look at how many other browsers implemented DirectShow filters. (Even on non-Windows platforms they should be emulateable)
• mildweed 11y ago
  This seems to be an appeal more to the W3C and browser developers than it is to the rest of us. He's not asking us to stop, in fact, he's asking us to double down and make use of the standards that we already have.
• _pmf_ 11y ago
  WebGL that more often than not crashes the browse, CSS animations that saturate an octocore ... one wonders if there are no more pressing matters.
• lojack 11y ago
  While I agree with the general idea, I completely and utterly disagree with both his examples and approach. First, it's almost like he's arguing that IE6 was a good thing for the web. This one completely boggles my mind. Yes, some people came up with some pretty creative tricks. Did it stifle innovation? Absolutely. Countless hacks were made that are arguably(?) worse than polyfills. These hacks persist even to this days. Further, modern browsers must take all of these hacks into account when moving the web forward. This is massive technical debt. Additionally, how many man hours were spent creating these hacks to deal with the shortcomings of IE6? That time could have easily been spent working on something awesome. The other example on page transitions is a bit more reasonable, so I'm being a little pedantic on this one. I agree that page transitions are a bit much, however why is a polyfill really necessary? All that being said, I agree with the general sentiment. We need to slow down and put thought into the features we're creating. However, I don't think we need to stop working for a year and see how everything plays out. What happens after 5 years? We stop for a year and continue as if none of this ever happened, then continue pushing things forward for 4 more years. Then we run into the same exact problems. We need to have a way to vet experimental features, and a plan to remove them (and old features) if they don't pan out. We've progressed far enough to where removing legacy features is as (if not more) important as introducing new ones.
• ommunist 11y ago
  Upvoted that article. I am tired too. I am not contributing to browser development, but I just want to get more work done instead of spending more and more time on learning.
• deleted 11y ago
  [deleted]
• cromwellian 11y ago
  I think PPK is missing the point being "features" being added, and rationalizing the design of the old Web APIs by making them a proper layered stack of primitives. Much of the work being added to the browser recently obviates the need for "high level" opaque features to be added, and instead exposes enough low level primitives that these can be implemented by developers in libraries. If you get a good set of low level primitives exposed that are freely composeable, then you can stop adding "features", and let third parties develop those features. The Web is missing lots of features for mobile that are being added today which simply cannot be replicated by freezing features and using IE6 era hacks. These are features that are needed not to emulate native apps but to make the end user experience of the Web better for end users. For example, ServiceWorker replaces the terribly designed Application Cache, and enables better caching logic, offline use, and push message delivery. If you're building a mobile site app for say, users in developing countries with very restricted data plans, than using ServiceWorker to control and preinstall cached resources, incrementally update those resources, possibly just by receiving a push notification, and allowing users to browse the site without even spinning up the cellular radio, that will be a huge boon to both the economics of the app in those regions, but battery life too. These rants don't come with any context of what the alternative is. The vast majority of human beings are now online via mobile as their only mechanism for content. The Web wasn't designed for mobile. It needs updating, and simply thinking we can return to the vision of XHTML Mobile/Mobile CSS circa 2004 era is not going to convince anyone. Either it will encourage Facebook Instant style destruction of the Web, with more and more content moved into proprietary silos, or you'll see something like Flash come back. Remember, we finally disposed of Flash by upgrading the Web to the point where it wasn't needed anymore. We don't want a similar situation to occur for the mobile web.
• k__ 11y ago
  We went from the stagnation to fast-forward. I hated the old days because nothing seemed to change. The browsers had slowed innovation because of IE and PHP didn't seem to try much new things (besides the OOP additions) for a long time. But it was easy money. I learned PHP, HTML and CSS and was set for about 10 years with subtle changes. Since 2013 I went from ExtJS, to Ember, to React on the client and from PHP to Node with Express and then Koa on the server. It got a bit more exiting, with all the new features and a much faster development pace, but I went from old, never fixed bugs to new unstable libraries. So the rage stayed the same, hehe.
• w0und 11y ago
  I couldn't agree more, we need stop and take a break. Enjoy the stuff we have now and fix what is not working correctly. Adding more features just adds more bugs and exploits, if you have been paying any attention to the web lately you would notice that the a lot of the bugs popping up are 10+ years old.
• bla2 11y ago
  PPK really lost it some time last year :-/
• altcognito 11y ago
  ATM, The two top articles (Why Docker isn't Successful in Production) and this one are both cries for the world to slow down. It's not going to and everyone ought to strap in. If change is called for, it will be adopted. If not, it won't. Some technologies were rejected simply because they came about at the wrong time. Some technologies that are adopted now will later be deprecated as better solutions are found. Change is constant. The article is premised on a distinction between "apps" and "the web". No such real distinction exists. The distinction is in the form factor and physical interaction. The software distribution model that mobile apps utilize was rejected outright in the 90's by both users and software companies. I don't want to worry about what % of users have a particular version of an app, what particular version of an OS a user is running (Android is not alone here), have my apps approved and taxed by a third party, or whether that app is properly discoverable. This is even before we get to the fact that developing for multiple platforms in the mobile world involves completely different skillsets and tools and therefore additional costs. Furthermore, "performance" is a secondary (albeit important) concern. There is no computing law that prevents the web from achieving reasonable parity with native apps. Funtionality and usability will almost always trump performance. The browser is a great VM, may the best features win.
  • chx 11y ago
    > If change is called for, it will be adopted. Please elaborate. This does not seem to be true but it's too short to fully understand.
    • altcognito 11y ago
      Well, if the market sees a technology as solving a particular problem it will adopt it. As you suggest, this is more complicated than nine words can cover. It may only be temporary -- like flash video. Up until flash video took over, the existing solution were plugins like RealAudio/Video. If mobile application development solve a pressing need better than other solutions, ideally it will be adopted. Of course, technical merits are not the only issues at play here. Marketing, costs both hidden and direct are all absolutely factors determining whether change will occur.
• awalGarg 11y ago
  PPK raises very valid points. I further want to add that you do not need flying boxes, fading tool-tips and what not to make your app look cool or even beautiful. In-fact it is pretty silly to try to make websites look very beautiful and cool because you can never cater to the taste of every single user. Your flying boxes which look cool to one person might look ugly and distractive to another one. Do we not have enough flame wars on whether iOS looks prettier than Android or the other way round? Google is popularizing a set of styles called "Material Design" and it's friends. Here is an example: http://www.google.com/design/spec/animation/responsive-interaction.html#responsive-interaction-user-input http://www.google.com/design/spec/animation/responsive-inter.... Here is another example of something more classy: http://motherfuckingwebsite.com http://motherfuckingwebsite.com. Why the first one is any better than the second one, only Google knows. We can have simple sites, like the present google home page, like the blog post you linked, like the second example I linked, etc. without emulating native, which do their work, and users use them with a lot of love. P.S. The question "why do you need smooth transitions" applies to native apps as well, PPK ;)
• Dysprosium 11y ago
  I don't see how pages transition is trying to emulate native apps. It still falls under the paradigm of accessing a resource at a given URI, which is what the web is. Personalizing the way the resource is loaded by the client and displayed to the user? That's just cosmetics we should definitely care about. Currently, the most popular way of implementing "native apps" in the browser are Single Page Applications, which breaks the web paradigm and hence have practical drawbacks such as the inability to open some resources in a new tab or to bookmark them. One motivation of SPA is the fact that loading a new webpage produces a blank intermediate screen during downloading, which is lame, especially for pages which are almost the same. Pages transition can change that, and in a beautiful way.
• unabst 11y ago
  An experience is not a function of a feature. The browser does not define the experience -- the web developer does. So to say creating too many tools is bad, if anything, is an attack on the web developer for misusing their tools. For this reason, we shouldn't be able to say navigation transitions are a bad feature. The onus is on the web developer to create a positive experience. >Do we want the web to be at whatever we push it forward to? It never became what we pushed it to. A new feature is unusable. Nobody building a critical page can use cutting edge features due to bugs and compatibility, and they are mostly for experimentalists and fiddlers. Only those with deep pockets can do the multi-platform web page which is building multiple web sites just for a handful to have a cutting edge experience, but even this trend is dwindling it seems with the death of Flash. A new feature, if anything, is an offering. It is a question posed to the web developers by browser developers asking them to examine a new opportunity for new experiences. The web developers then tell the browser developer community whether they love the feature or hate it, and this is how the web has organically evolved. Therefore, it can only be a good thing that finally all these features are being pushed to production so that all these questions can be posed. So do we love them or hate them? The browser developers focus should be on pushing cutting edge features forward, and not on experiences. Leave that to the professionals, and mock their work if you have to.
• pc86 11y ago
  > here is an artist’s impression of the modern browser > screenshot of Microsoft Word in a 14-year old unsupported OS on what is most likely a 1024x768 screen with all toolbars activated
• frik 11y ago
  What's wrong with that site? quirksmode.org used to be a great resource but it stopped being updated 10 years ago when IE 6 was still the "thing". Nowadays, http://caniuse.com http://caniuse.com replaced it. So quirksmode transformed to a rant blog, like this one we had on HN three months ago: http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html http://www.quirksmode.org/blog/archives/2015/05/web_vs_nativ...
  • notNow 11y ago
    He's clearly over the hill. He feels left behind with all the progress and growth in the community and his cry wolf shouting style from the mountain top is just pathetic. As we say here, the dogs bark but the caravan moves on.
• z3t4 11y ago
  Even though I'm a bit butt hurt about the new syntactic changes to JavaScript, I very exited about the browser development. Hardware accelerated Canvas 2d graphics and Web-sockets are the two I'm most excited about because they are now stable across most browsers.
• davesque 11y ago
  I can't disagree more with his critique of navigation transitions. Transitions are the best way people can create a great user flow without needing to structure their web app around the single-page, stateful, AJAX (or WebSockets) paradigm. If you think transitions are a bad idea, I hope you think single-page apps are a good idea. And if you think that the web just wasn't meant for that level of native-app-like functionality, I think you're not going to win that argument against the real demand for those kinds of offerings on the web.
• macu 11y ago
  I constantly get the sense that I am missing whole swaths of the configuration options available in mobile and web development. The fact is, a dedicated team with experience will know how to tweak variables for an excellent product. New possibilities are continually arising but not everyone will use them. A lone developer is likely to produce something more retro. Experience and dedication pay off as you develop finer control.
• buckbova 11y ago
  > We’re pushing the web forward to emulate native more and more, but we can’t out-native native. I can do better than native. I can update web apps without troubling the end user, fix bugs and make improvements immediately. I can balance processing where heavy lifting is done on my servers and simple processing done on the client. I can store immense data in the cloud freeing the end user's machine from any such junk, aside from maybe a cookie, and stream it on demand. Why should someone have to install anything on a phone, tablet or PC? Feels archaic. Open browser. Navigate to URL. Do work, enjoy media, etc.
  • pholmq 11y ago
    Best comment so far! The web is a multi platform client-server application environment. Sanboxed so that unsecure (javascript) code can be downloaded and executed at runtime. THIS is the killer feature of the web. No other app environment has this and Web and JS will eat native apps in the long run because of it.
  • pdkl95 11y ago
    > I can do better than native. No, you can't. Not even close. Just because you only ever use a subset of what can be done in a native application doesn't mean the rest of us don't. Also, which "native"? Win32 != OSX != X11 != mobile != ... > I can update web apps without troubling the end user, Which makes you the source of one of the most common types of user frustration: apps that change without their authorization, sometimes breaking important things that used to work just fine. > ... processing ... done on my servers ... Ahh, so you just want to lock people in using Service as a Software Substitute[1]. Trying to do an end-run around "1st sale" rights to insert yourself as a middleman where none was needed previously is terrible, sociopathic behavior. > I can store immense data in the cloud freeing the end user's machine from any such junk, aside from maybe a cookie, and stream it on demand. The user also has to trust that you will handle their data sanely (and not "monetize" - including using or selling the analytics of their usage patterns). They have to trust that you will not betray them and hold their data for ransom. They have to deal with the fact that you will hand over any of their data in bulk when the government shows up with a national security letter. They have to trust that you are competent at programming and have not stored passwords or allowed their data to be stolen. The trade off being made by storing data remotely is huge, stop pretending it doesn't exist. > Navigate to URL And when internet access isn't available? Don't believe for a second that this isn't a problem. The reasons why are far too numerous to list; it would require a lot of wilful ignorance to pretend otherwise. > Why should someone have to install anything Because they like to actually use all of the features a native app can provide? Because they don't want to risk their data with an external service? Because they don't want to depend on the availability and whims of an external service? Because they are tired of the lies and doublespeak the computer industry has been saying about "the cloud"?[2] [1] http://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html http://www.gnu.org/philosophy/who-does-that-server-really-se... [2] https://projectbullrun.org/surveillance/2015/video-2015.html#balkan https://projectbullrun.org/surveillance/2015/video-2015.html...
• applecore 11y ago
  Navigation transitions actually sound like a pretty good idea, considering it emulates one of the most salient features of a single-page web application.
  • TazeTSchnitzel 11y ago
    And, ironically for an article calling for "care for user experience", is proposed to improve user experience.
• PSeitz 11y ago
  > Quick, name all the new features browsers shipped in 2015! You see? I don't know all features shipped of any year, so I guess this point is invalid. I don't see anything bad in moving forward, when the things are well thought. And most are imho.
• codeshaman 11y ago
  That happens all over tech, not just in web browsers. Just for fun, I've spent a couple of minutes compiling a list of technologies, just for the backend side of things, which many of us know or have heard of, which ilustrates the complexity and diversity that we have in our industry atm. It's both beautiful and scary at the same time - how will we be able to move all of that into the future ? How will we scale our brains as we get older ? So here it goes. You want to implement something on the Backend ? Nothing can be easier! Step 1. Pick a language. C, C++, Go, Java, Ruby, Python, Dart, PHP, Hack, Erlang, D, Xhp, Javascript/CoffeeScript, TypeScript, Perl, Scala, Scala, Clojure, Lisp, ColdFusion, or ASP.NET (C#, VB, F#)? (https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites https://en.wikipedia.org/wiki/Programming_languages_used_in_...) Step 2. Pick a framework for the selected language: ASP.NET, Ruby on Rails, ASP.NET MVC, Django, Meteor, Laravel, Spring, Express, CodeIgniter, Symfony, JSF, Flask, Flex, CakePHP, Zend, GWT, Play, Yii, Sinatra, Tornado, Grails, Struts, Dojo, web.py, Wicket, Bottle, Pyramid, Kohana, Koa, web2py, Yesod, Revel, (fab), Gin, Compojure, Martini, Vaadin, beego, CherryPy, Ring, Scalatra, Mithril and many more (http://hotframeworks.com/ http://hotframeworks.com/). Step 3. Pick a database: Oracle, MySql, MSSQL Server, MongoDB, PostgreSQL, DB2, Access, Cassandra, SQLite, Redis, SAP Adaptive, Solr, Teradata, Elasticsearch, HBase, FileMaker, Hive, Splunk, HANA, Informix, Memcached, Neo4j, CouchDB, Couchbase, Firebird, MariaDB, Netezza, Azure SQL DB, Amazon DynamoDB, Vertica, Riak, MarkLogic, dBASE, Ingres, Sphinx, Endeca, Greenplum, Ehcache, Interbase, Amazon Redshift……. http://db-engines.com/en/ranking http://db-engines.com/en/ranking Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures. Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end ! Given that most of these have been created in just the last 15 years or so, what will the next 15 years bring ?
  • yellowapple 11y ago
    > Step 1. Pick a language. Since the focus seems to be on web backends (given the section following this one), I'd imagine that trying to use C or C++ for such a thing would not be one of the obvious choices. Also, you've listed Scala twice, I'm pretty sure Xhp and Hack count under PHP, and God help you if you opt to use ColdFusion or ASP.NET (or PHP, for that matter) in anything new. > Step 2. Pick a framework for the selected language: Once you've picked a language, you can usually narrow down the selection quite a bit. For some languages it's a bit harder, but for most, the choices are manageable. C/C++ -> Raphters, CppCMS, WSO2, Wt, ffead-cpp Go -> Revel, Martini, Gorilla Java -> Spring, JSF, Struts, GWT, Play, Grails (if we count Groovy as Java), maybe some others that I haven't heard of yet Ruby -> Rails, Sinatra, Padrino (which is basically Sinatra plus some helpers for databases and views), camping (if anyone actually uses camping in production, please let me know) Python -> Django, maybe some others (but Django's the only one I hear about regularly) Dart -> does anyone even use Dart? I'm pretty sure even Google has moved on to Go for backend stuff, and the plan to integrate Dart with Chrome was apparently cancelled. PHP -> Laravel... I can't think of any others that I've actually seen used. Pretty much every PHP app I've encountered was CGI-based. Erlang -> YAWS or ChicagoBoss. If you're counting Elixir with Erlang (we might as well), then we can throw in Phoenix and Sugar. D -> vibe.d is the only one I know of Javascript -> Node.js, probably. Perl -> Catalyst, Mojolicious. Or just use (Fast)CGI. Scala -> Play, Scalatra, Lift, Sweet, Slinky Clojure -> Compojure, Webjure, Conjure, Moustache Lisp -> (Common -> Weblocks, possibly Hunchentoot), (Scheme -> SISCWeb (via J2EE)), Racket ColdFusion -> ColdFusion. I don't know if ColdFusion doesn't instead count under the Java category, though. ASP.NET -> I dunno, ASP.NET? Basically, once you have a language picked (based probably on which one looks the best to you), it's pretty straightforward to search the web for "$LANG web frameworks" and find some sort of comparison between them. > Step 3. Pick a database: If you're not picking PostgreSQL, then you're wrong, end of story. Maybe CouchDB or Mnesia if you know for sure that you need their replication features and are aware of the tradeoffs of using a non-relational database. SQLite deserves special mention, because while it's absolutely wonderful for end-user applications, it's not at all ideal for server software except for specific use cases (like using it as an offline data storage format, e.g. for backups or data imports/exports). MongoDB, Oracle, MS SQL Server, and MySQL also deserve special mention because, if you're using them willingly in a new application (other than to interface with a legacy system that did involve such a regrettable choice), you're probably not right in the head. In particular, there's pretty much zero reason to use MySQL instead of MariaDB (which is also arguably marginal due to its MySQL heritage, but at least it's slightly better), using a commercial database like MSSQL or Oracle is basically begging for vendor-lock-in-related problems, and MongoDB... Jesus fuck-me-in-the-ass-with-a-pogo-stick Christ. Might as well just pipe your data to /dev/null while ranting about how it's "web scale" while we both transform into 3D-animated bipedal animals and I resign from my job as programmer/sysadmin and go shovel pig shit for a living. > Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures. If you're smart, you'd go with Cloud Foundry, since a large number of PaaS vendors support it, so you can pretty much just pick whichever one has the best bang for the buck (might I suggest IBM Bluemix?) and use the `cf` tool to deploy to it. Additionally, if you're using containers of the Docker variety, the vast majority of PaaS and hosting companies nowadays support them with little to no modifications, so - again - the choice matters very little beyond one's priorities regarding performance, location, and cost. > Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end ! Now that is a massive can of worms. So many frontend frameworks. So little time. And pretty much all of them constrained to the quirks and pains of Javascript. Of course, you could just go with straight HTML and CSS (plus a smattering of JS using JQuery or Mootools), which is what I generally prefer to do in most cases.
• PSeitz 11y ago
  >But why do web developers want navigation transitions? In order to emulate native apps, of course. You got this one quite wrong. It's not about emulation, it's the feature. Reducing the perceived delay with an animation. There is nothing wrong with an improved webpage experience ...
• qwtel 11y ago
  Just let the browser do what "applications" did in the 90s, while not breaking the stuff that browsers did in the 90s.
• overgard 11y ago
  Who's "we"? I know it's a blog and he's probably just going for a colloquial tone, but I always find this notion of some great big web development community weird. The web is countless tribes with differing goals, and if your call is to non-action all you're really doing is leaving the future to those that act.
• 392c91e8165b 11y ago
  One thing I do to try to slow down the rate of change on the web is to upgrade my browser less often than most people. Specifically, I use Firefox Extended Support Release (ESR). Mozilla resisted providing this "update channel" (Firefox ESR) for years, but eventually yielded to the desires of large IT departments. Despite Mozilla's writing that "Firefox ESR is meant for organizations", with only one or 2 minor problems (with plugins IIRC), which I easily solved by upgrading temporarily to Firefox's normal ("release") "update channel", I've used it personally for years. Below is a link to the best page I've been able to find to download Firefox ESR, but note that both version 31esr and version 38esr are available from the page below. Version 31esr is still supported with security patches and is what I have been using. It is my understanding that before it stops getting security patches, version 31esr will automatically upgrade itself to version 38esr. https://www.mozilla.org/en-US/firefox/organizations/all/?q=english+%28US%29 https://www.mozilla.org/en-US/firefox/organizations/all/?q=e...
  • immibis 11y ago
    > will automatically upgrade itself No no no no no no no no no no no no no no no no no no no. No. Just no.
• datashovel 11y ago
  I think we need two primary things to solve this "problem". 1) we need more browsers I know this probably sounds counter-intuitive, but I think I have a good explanation for it. 2) we need to allow developers to "choose" browser of choice that renders their page / app / whatever in the (what I would call "meta-browser"). The architecture of browsers is incorrect in that instead of having a few browsers, all of which developers must support, we need one (or a few) "shell applications", which "host" browsers. Browsers can then begin to become specialized and diversify in directions they want to (instead of forcing everyone to stay up to date with everything). Today I agree, it's a circus, trying to keep up with things, and figuring out how to mash stuff together in order to ensure cross-browser compatibility. So, how do we get things to a point where a developer gets to "choose" the browser for the user? Probably one of the simplest would be to pass HTTP headers which tell the "shell application" which browser to render the web app / site / whatever in. There is not enough room in one HN comment to explain the nuances that I think can be solved relatively easily (ie. security, user confusion, etc). I did write a blog post that explains more or less what I am talking about here: https://medium.com/@datashovel/why-isn-t-there-a-meta-browser-204997473c61 https://medium.com/@datashovel/why-isn-t-there-a-meta-browse...
  • datashovel 11y ago
    With all that said, I really do hope the OP was saying all he had to say in jest. It seems ridiculous that one person should have any expectation they (no matter how well known they are to the community) can stand up in a crowd of 7 billion people and say "hold on, let's stop and think about what we're doing". This assumes all 7 billion (or even most of them) are not thinking before doing, or can't possibly be certain about what they're doing without express written consent of OP. Just because one person can't possibly keep up with all that is happening in the world doesn't mean everyone should feel obligated to stop to allow them to catch up. OP also seems to imply it'll be near impossible to reverse out of what is going into the web, no matter how good or bad those decisions are. I think it's a bad assumption. Things will continue to move forward. Whether that means one company or two decide to take two steps back is another question, but in general the web will (and should) continue moving forward. It's a great idea to have "web as platform", and not "web as html and links". Please web, don't change direction of your thinking. You're on the right track. We just need some relatively minor architectural changes to make it go more smoothly for more people out here doing what we're doing.
• colemorrison 11y ago
  I'll make the opinion purely from a self-interested developer standpoint: I'd rather push the web forward and have it at least stay "somewhat" close to native (no it'll never be better) and constantly learn new features... rather than: .... have it lag behind native even more and thus create even more pressure on myself, my company, and my career to adopt, learn, and build native alongside web.
• bcheung 11y ago
  If you can't keep up then don't. Some of us have ideas we've been wanting to implement and are just waiting until a browser feature becomes available and widespread enough that it is a possibility. I don't want to have to develop for the web and an Android app. I don't want to have to develop for the web and an iOS app. I don't want to have to develop for the web and a .NET app. I don't want to pay 30% to a company just so they will let me deploy MY OWN app to MY OWN users. I don't want to have another company dictate what I can or can not provide to my users.
  • grgbrn 11y ago
    I'm not sure how you square "If you can't keep up then don't" with what sounds (to me) a lot like "I have an idea that I want to implement, but only if I don't have to learn anything new" To try to be at least somewhat constructive: I took PPK's argument as: "Trying to cram everything and the kitchen sink into your browser so that you don't have to ever write native code may be appealing, but it risks collapsing under it's own weight." Which, to me, doesn't seem so ludicrous that it deserves to be shouted down.
    • notNow 11y ago
      The guy is clearly over the hill and his old glory is over. He made a bet to chase and document every silly and ridiculous quirks in legacy browsers and established a name in this 'field' during the Great Web Depression 2000 - 2005 now that these days are gone and no one is interested to listen to what IE6 or Microsoft dictates on the community and we're living in a true Renaissance and booming expansion, his desperation and frustration with losing bets and falling behind his peers are showing but his phone outrage and indignation are not fooling anyone. He was asking for it by shunning modern and progress in web development and instead endorsing everything that's reactionary and antiquated in the field and his latest outcry hopefully the last would be just a blip on the radar and we would be moving forward nevertheless. You reap what you sow
    • bcheung 11y ago
      It's not the learning or the hard work that concerns me. I'm all for that. It's proprietary walled gardens for the most part. I want to build apps that I already know Apple won't approve so that leaves me with a reduced ability to service my users until mobile web gets better.
• intrasight 11y ago
  I'll state it somewhat differently: Stop pushing the specs forward - finish implementing the specs. If all those spec writing engineers were told "sorry, the spec store is closed", they might actually get their hands dirty writing code for the current specs. Hell, I might even lend my tired old hands if there were a moratorium on new specs.
• rabbyte 11y ago
  Native emulation has been a goal of the web from the beginning. I can recall several efforts as far back as '96 to create websites to replace desktop apps and we arguably achieved that around 2005 with apps like Google Maps or Writely. Two years before the iPhone was released we were chasing the tail of "native". The web vs native debate skips over the idea that these two worlds actually inform each other and are largely populated by the same developer community. As an industry, I think people are starting to place more value on the comprehensibility of software over its capability and that's where I think PPK hits home here. When you're building to satisfy immediate needs it makes sense to eventually stop and revisit your implementation to make sure (1) those needs are still relevant and (2) your implementation adequately satisfies them. That's what I see this as, not a call to stop chasing native, but a call for replacing the patchwork with comprehensible design. I think that's perfectly reasonable and I would go so far as to say we should build it in as a cultural value to pause every 10 years to both celebrate what we've accomplished and refine the result.
• est 11y ago
  Anyone tried to use the HTML5 File API manually? It's a cluster fuck unlike any of good old javascript. > Navigation Transitions Seriously? It's like Frontpage 99 again.
• jay_kyburz 11y ago
  I didn't see this discussed below, but I think when PPK says web’s strengths: simplicity, URLs and reach. I think he misses an important feature for me, as a user: Security. I just don't trust native apps. Even a non-malicious app can undermine your systems performance and behave badly. I've spent too many hours trying to "clean" windows systems, there is just no way I want to be installing native apps on them any more. My windows machines have the OS and its bundled apps, MS Office and that's it.
  • immibis 11y ago
    Mobile apps are sandboxed already. Windows is also pushing towards sandboxing desktop apps, but look at the backlash that's received. (Although they implemented it poorly - there are two completely different types of apps, and you have to choose one?) (Also, realistically, installing trusted unsandboxed apps generally goes fine, because if they were malicious you would've heard about it by now)
    • jay_kyburz 11y ago
      How do you define _trusted_ apps. The windows app store is full of junk.
  • notNow 11y ago
    The web browser itself is a native app. so why do you think it's ok not to trust native apps (not to discredit your reasonable concern) but it's alright to go ahead with web browsers?
• jv22222 11y ago
  Part of the beauty of new innovation and new features is that you don't know what people are going to do with it. Many of the best things about the web are features that we didn't originally plan for but created using javascript and such, then we folded it back in to the specs. When you add something new, most likely someone somewhere will do something very cool with it in ways we could not have envisioned.