7 ms·

The web is now hamstrung by the HTML/CSS layout model more than anything else. The hackery required to attempt to imitate native mobile apps is horrific. Googl

The web is now hamstrung by the HTML/CSS layout model more than anything else. The hackery required to attempt to imitate native mobile apps is horrific. Google would be better off throwing efforts into a new layout engine leveraging raw JS and WebGL, but with a sane API, than these continuous attempts to push HTML into places where it doesn't work. If they don't lead it I can see someone else doing it in such a way that their core money maker of web scraping and indexing ceases to work.

addyo 12y ago
On the Chrome team we're always looking at ways to better provide access to lower level primitives and machinery to enable you to do things like this. It's a multi-faceted problem however. If you have specific suggestions around alternative layout engines, discourse.specifiction.org is a great place to lay out your suggestions in more detail (not that HN isn't useful for this, but those interested in standards generally frequent the discussion board). Outside of layout engines, we're also looking at enabling developers to do more things they would like to with native hardware. Take a look at https://github.com/w3c-webmob/web-api-gap/tree/master/features https://github.com/w3c-webmob/web-api-gap/tree/master/featur... for feature gaps and efforts to fill them.
- jlhonora 12y ago
  Android's layout structure could be an option. It is much easier to handle than HTML + CSS, IMHO.
- fidotron 12y ago
  To be clear, I think in the medium to long term other than legacy HTML support browsers will get out of the layout engine business. Layout belongs in the JavaScript layer (or similar execution env) on top of a lower level abstraction, which is why I picked out WebGL as the most likely contender. Then the on the wire format becomes pure semantics, which can either be semi standardised, or not. (And Google clearly have an interest in promoting the former). WebGL, as it stands, seems to lack a few useful primitives for such a task, most notably needing an equivalent to process separated iframes. That might be possible already, but if not I'm sure it will be cracked enormously faster than attempting to debate and implement tiny incremental improvements in the HTML spec. My understanding is this is remarkably close to how the PS4 UI is actually implemented already.
marknutter 12y ago
> The web is now hamstrung by the HTML/CSS layout model more than anything else Really? Because I find it far more intuitive and flexible than working with xibs, for instance.
- adamnemecek 12y ago
  Well, xibs solve a bit more complex issue.
  - marknutter 12y ago
    That being?
    - adamnemecek 12y ago
      I mean with Xib, you can e.g. specify how the window should behave when you are resizing it since you are specifying layout constraints as opposed to having to hardcode the layout. With CSS, your only recourse is media queries but those are a lot less fine-grained. Look into http://gridstylesheets.org http://gridstylesheets.org (and more specifically http://gridstylesheets.org/guides/ccss/ http://gridstylesheets.org/guides/ccss/) which is kinda the love child of CSS and Xib (or the technology that inspired the layout technology).
      - ggamecrazy 12y ago
        Are you talking about Auto Layout? You can write the same thing programmatically, in fact it's quite nice, though not as obvious as modifying frames.
        adamnemecek 12y ago
        I was. But you are still hooking into the same layout API as if you'd use IB.
      - marknutter 12y ago
        I still don't understand why the issue is more complex for native mobile apps than it is for web mobile apps? Don't they all have to accommodate for the same screen sizes?
pjmlp 12y ago
Web was never meant for applications. Other hypertext models like Hypercard and Xerox PARC experiments had better support. I really hope that we can sort out this mess some day. I personally like apps are making the network more relevant than the Web. What matters are communication protocols.
- sdegutis 12y ago
  Who could fix it? What organization or individual could possibly create an architecture that all of the web could be ported to, that's better than our existing web? Especially considering we usually get pretty upset at companies for trying that.
  - DanBC 12y ago
    You don't port "all of the web". You have apps that the Internet. You also have the WWW. People developing apps can chose whether to also develop for the WWW. Hopefully this would stop people doing stupid horrible things on WWW (forcing fonts; preventing zoom; etc) because all that hateful stuff can be done in their app and doesn't belong on WWW.
  - malandrew 12y ago
    No one needs to "fix it". What we need is more safe low level primitives from the user agents, that allow many individuals and companies to explore building alternatives in the browser. Then from two or more approaches, some standard will eventually shake out through the standardization process. Most features we have in the web started with a feature in one web browser, that others copied and eventually became a standard. If the browsers exposed more low level features, more people could contribute ideas on how to "fix" the problem. Browsers should be written to expose APIs needed by the same people that write native applications today, but do so using a more appropriate trust and sandboxing model than what operating systems do. The browsers should act as "user agents" advocating on behalf of the users while exposing as low level and powerful APIs as possible and then standardizing those ideas that are well baked. edit: regarding low level primitives, this comment [0] in this thread by addyo (Addy Osmani) is relevant. This low-level work is crucial. [0] https://news.ycombinator.com/item?id=7917493 https://news.ycombinator.com/item?id=7917493
adamnemecek 12y ago
Indeed. I'm surprised that the whole Cassowary hasn't taken off. It's been around since '99. The fact that it hasn't is probably one of the worse is better 'typathingys'. http://en.wikipedia.org/wiki/Cassowary_(software) http://en.wikipedia.org/wiki/Cassowary_(software) https://www.cs.washington.edu/research/constraints/web/ccss-uwtr.pdf https://www.cs.washington.edu/research/constraints/web/ccss-...
- agumonkey 12y ago
  Didn't know it was the logic behind http://en.wikipedia.org/wiki/Scwm http://en.wikipedia.org/wiki/Scwm
- adregan 12y ago
  drewda's comment below[1] is an example of a JS library that implements Cassowary in the browser. It's called Grid Style Sheets. 1:https://news.ycombinator.com/item?id=7917646 https://news.ycombinator.com/item?id=7917646
  - girvo 12y ago
    And it's awesome. Where I'm working we've embedded it into Node-WebKit for an app we're building ;)
drewda 12y ago
A partial bit of progress toward a better layout model: http://gridstylesheets.org/ http://gridstylesheets.org/
- jacquesm 12y ago
  If you make that page really narrow there is an ugly purple bar that comes into view from the left that overlaps a part of the content.
Jonovono 12y ago
Been following this project for awhile: http://www.nidium.com/ http://www.nidium.com/ . Hopefully they launch soon cause I am curious to try it out.
- agumonkey 12y ago
  I'm affraid they'll turn into vaporware.
- malandrew 12y ago
  I found these two bullet points truly odd "Yes, it's a kind of browser, and you can browse online webapps ... We do not support HTML & CSS". You don't need to throw HTML and CSS out wholesale (it still has uses) and you don't need to implement an entire browser to get many of the features listed on that page (except maybe the audio stuff). At famo.us [0], we're doing a lot of the things they say their final product will have but within the context of any modern web browser. [0] https://github.com/famous/famous https://github.com/famous/famous
agumonkey 12y ago
I'm personally waiting for distributed Self objects. When we cut the document presentation mindset maybe ...
yesimahuman 12y ago
Horrific is an exaggeration. You may not like it, but that doesn't mean it's overly difficult to build native mobile UIs with standard HTML and CSS. Also, Flexbox makes this even easier, and is a great step forward.
vlunkr 12y ago
I disagree, HTML/CSS have come a long ways in the past few years, in terms of browser compatibility and features. I don't see how introducing a new layout engine would help. That's just another standard that every platform has to support. Using WebGL would be great, but so far WebGL support on mobile is not great. If you haven't worked with web tools recently you should see how far they've come. With JS frameworks like Angular or Ember, and crazy fast build tools like Gulp, it's pretty nice developing for the web these days
- rimantas 12y ago
  > If you haven't worked with web tools recently you should > see how far they've come. And if you take a good look what native SDKs offer all that progress looks laughable.
lukifer 12y ago
In particular, the broken implementation of CSS position:fixed on all mobile platforms is probably the major stumbling block preventing app-like interfaces for the mobile web. I have been frequently tempted to try to build a canvas-based interface from scratch, but I suspect even that would run into the same problems.
- _broody 12y ago
  I think app-like interfaces on the web are a pipe dream at this point, anyways. Attempts to emulate native interfaces inevitably get stuck in a java-like uncanny valley that's nearly as hard to get out of as it would be rewriting native apps for each platform from scratch. For all the talk of web apps as credible alternative to native ones, the fact is the current toolchain is unlikely to ever be good for anything more than paper-thin clients. Ecmascript 6 doesn't fix this, Ecmascript 7 won't fix it. HTML5 tags are a worthless collection of semantic sugar when we desperately need a solid component library instead of implementing everything from scratch.
  - simonw 12y ago
    "HTML5 tags are a worthless collection of semantic sugar when we desperately need a solid component library" What's your opinion of Web Components?
  - lukifer 12y ago
    Agreed that a richer component library is badly needed. However, native apps can and do frequently invent new UI paradigms outside native (games in particular like to invent their own UIs, to varying degrees of success). Rather than poor imitations of native, I think web apps UIs would do well to draw their own cross-platform custom UI elements. I don't believe that interoperable and usable web apps are a mere pipe dream, on desktop or mobile; can you imagine a world in which the open web never took root, and we were all stuck on AOL, Compuserve, and Prodigy? That's the current app ecosystem in a nutshell, and it's deeply suboptimal for both users and developers.
protonfish 12y ago
This is the same complaining I always hear from people who don't want to learn how to use HTML and CSS. Yes, it is different than what you are used to. Yes, it will take some time to learn and some of that will be uncomfortable. But that does not mean that that HTML and CSS are bad. I know this because I successfully build mobile sites that look and function fine and I assure you it works. You say "hackery is required to attempt to imitate native mobile apps" and I agree with you. Can I ask why it is so important to copy the styling of native? That seems like a lot of effort for no good reason. Mobile web can be better than native if you let it, but forcing it to be something else purely for reasons of fashion is foolish. HTML/CSS produces a flexible layout that is usable by many different sizes and types of devices (even audio interfaces) and that is a good thing. It takes effort to get it working for all of the possible ways it could be used, but it is possible. After a little practice, it can even get easy. The hard parts of HTML/CSS would still exist in any flexible layout solution. Making a rigid screen-painted layout solution avoids problem inherent in flexible layouts those, but it gives up so much.
- malandrew 12y ago
  If you're not using HTML/CSS for documents then yes it is bad. It's fundamentally the wrong abstraction. I began my career with HTML and CSS and after seeing alternatives, there is no doubt in my mind that trying to build apps on HTML/CSS is fundamentally wrong. I'm not saying that there aren't a lot of good ideas introduced by the web (documents, hyperlinks, semantic metadata, responsive layouts, accessibility, URIs, etc.). What I'm saying is that there are good parts and there are bad parts, just like with native. What we need is a marriage of the good parts of the web with the good parts of native. We can do better. Much much much better.
  - diminish 12y ago
    most of the development frameworks called native, are built on the precursor of html, namely 90s and earlier native app apis, on guis, and they arents perfect abstractions for apps neither. Current native zeitgeist gets its allure mostly from being closer to hardware and is the assembly to C. Otherwise all major mobile GUI APIs are naive attempts by busy developers to imitate, layouts, stylesheets,....
spitfire 12y ago
If we're throwing out HTML/CSS why on earth would you keep Javascript? (or also contentiously - HTTP) If we're throwing away the cruft (which I fully support!), lets do things right. That means planning a (light) abstraction layer for a world where you can use the right tool for the job.
- malandrew 12y ago
  Javascript is not the problem (though I think we would all be better off with more variety like NaCl would have provided). I'm actually starting to wonder if an approach like docker/lxc, but with web features ported to native land may not end up making more sense in the long term. The idea would be to take all the features of the web that aren't document focused and make them available in userland in a linux container. For example, the linux container would have to ask for permission from the host operating system to get GPS access or Contacts API access. It would also support the ability to use URIs to manage the state of any chromeless "window" object. It may be easier to take the web to sandboxed containers than bring all the operating systems concepts to the browsers. Basically this would be a LXC User Agent.
  - walterbell 12y ago
    > It may be easier to take the web to sandboxed containers http://httplocal.com/ http://httplocal.com/ is working on local composition of web pipelines. Micro Xen (Bromium) forks a virtual machine with a fresh copy of the host operating system and browser for every URI. What do you think of iOS8 extensions and Android intents? Or https://sandstorm.io https://sandstorm.io ? The challenge is maintaining security and composition flexibility. Apple only opened up a few APIs.
malandrew 12y ago
I'm so happy that this comment is here and the top most voted comment. I keep making this point every time web apps come up. I still don't understand why the user agents still haven't started work on a retain-mode scene graph for the web that plays nicely with HTML when a document is needed. I really want a graphics system in the browser that can do the types of things being done here: https://news.ycombinator.com/item?id=7896773 https://news.ycombinator.com/item?id=7896773 i.e. Wayland for the Web with documents If we jump on this now, maybe we won't be left in the dust when native makes the jump from 2D to 3D and interface devices like the Oculus Rift go mainstream. This is probably 5+ years away, but now is the time to start considering how these capabilities will be possible at the lowest levels. None of this precludes the entire 2D web we're familiar with since 2D is simply an elevation view of 3D. Baking 3D in from the start leaves room for people to explore the possibilities people are exploring on native instead of being hamstrung by naïve technological choices. We're trying to explore what is possible here at famo.us [0]. Hopefully between what we're doing and what others are exploring, we'll come up with some interesting approaches that eventually made their way somehow to becoming a standard. The w3c spends too much time trying to expose APIs for the jQuery level developers instead of seeing the web as an operating system and exposing operating system primitives from day one. All they need to do differently from how previous operating systems worked is consider how the semantic web, accessibility, and URIs fit into this computing model. relevant: http://acko.net/blog/shadow-dom/ http://acko.net/blog/shadow-dom/ [0] http://famo.us/ http://famo.us/
- d1plo1d 12y ago
  Edit: just FF'd to the 3d cube bit.. nm. We can't do that without WebGL. That's what I get for not watching the entire video. Not sure what your getting at. The Wayland demo looks like it could be completely recreated with existing CSS3 3D transformations. Here's a similar example in a browser using HTML and CSS3. These transforms can be used on anything you can fit in a DOM element: https://www.webkit.org/blog-files/3d-transforms/morphing-cubes.html https://www.webkit.org/blog-files/3d-transforms/morphing-cub...
  - malandrew 12y ago
    Not exactly. If you browse down that thread and read the dissertation and the accompanying slides, you see that that demo goes well beyond positioning a rectangle (texture) in 3D space (which we already do at famo.us). That guy went on to explore cuboids in addition to rectangles as a basic windowing primitive.
grey-area 12y ago
For the majority of web content today, HTML5 is actually surprisingly appropriate, if a little verbose. I'd contend it is also appropriate for most documents/data of the future too - WebGL is not required or suitable for most content (which is text/media based, not 3D models or animated shapes). Of course some widgets or effects might use GL behind the scenes, but the browser should insulate the users from that sort of thing, and GL is hardly a model API either. A raw JS and WebGL engine would be a creature of nightmares if you ask me! If you consider the content on a page of comments like this one, what improvements would a WebGL engine give you? The real pain points in the web of today speaking from a web developer perspective are CSS, JS and the DOM. It'd be nice to see the webkit browser makers get behind alternative style sheets, and alternative languages/APIs, because both CSS and the DOM have serious flaws and omissions which, while they are slowly being addressed, still cause a lot of pain. It'd be great if language creators could write plugins or compilers to see their language of choice as a sandboxed language available on the web, and see those bundled with browsers, and it'd be great if browser developers took a serious look at alternatives to CSS for layout - something much simpler could work so much better, and maybe we need different styling languages for different purposes (for apps or for documents for example). HTML is pretty flexible and people could always define fallback CSS for browsers that didn't support the new stylesheet variants. There's no reason browsers can't support a few languages with improved DOMs and a few styling languages. Sadly, I suspect we'll just see browsers bumble along adding some modules on CSS and improvements to JS instead. One of the big attractions for me about server-side development and HTML is that you can use whatever you like on the back end, as long as you feed the client HTML. It'd be lovely to see that sort of freedom to experiment extended to the front-end as well. If the web is to be an operating system, let it be an open one.
fred_durst 12y ago
When having these Native vs Other discussions, is it possible you could use something more specific than the word native? It means a lot of different things to a lot of different people. For example is declaring layouts in an XML file in an Android app considered native in this case? I've heard others say that Android apps that run on the Dalvik JVM should not be considered native. Maybe you are talking more about Cocoa or Windows?
- pjmlp 12y ago
  Native is whatever the operating system uses for user space applications. Android uses Java, C and C++ for user space applications, hence native Android means all three languages using Android APIs.
  - deleted 12y ago
    [deleted]
LordHumungous 12y ago
Personally I'd rather use HTML/CSS than Android's xml (blech) layout syntax
deleted 12y ago
[deleted]
rl3 12y ago
>Google would be better off throwing efforts into a new layout engine leveraging raw JS and WebGL, but with a sane API, than these continuous attempts to push HTML into places where it doesn't work. WebGL is great when what you're trying to do simply can't be done in a high-performance manner using standardized markup. However, a generalist WebGL-powered UI framework would suffer the same drawbacks that Flash/Flex/Silverlight did: your content ceases being semantic. Of course, some sort of convoluted metadata system to preserve this could be devised, or simply run parallel to real markup that's not rendered, but those types of solutions are ugly at best. In my opinion, if you're going so far as WebGL to achieve UI performance in a mobile context, you should probably just make a native mobile app instead. At the moment, WebGL support on mobile tends to be incomplete and suffers from poor performance on most devices anyways. Mobile will always lag behind desktop in terms of browser performance and features, but browser optimization and mobile hardware is improving every day. Keep in mind that both desktop and mobile browsers already utilize GPU acceleration in some aspects of rendering normal content.
deleted 12y ago
[deleted]

addyo 12y ago

On the Chrome team we're always looking at ways to better provide access to lower level primitives and machinery to enable you to do things like this. It's a multi-faceted problem however. If you have specific suggestions around alternative layout engines, discourse.specifiction.org is a great place to lay out your suggestions in more detail (not that HN isn't useful for this, but those interested in standards generally frequent the discussion board). Outside of layout engines, we're also looking at enabling developers to do more things they would like to with native hardware. Take a look at https://github.com/w3c-webmob/web-api-gap/tree/master/features https://github.com/w3c-webmob/web-api-gap/tree/master/featur... for feature gaps and efforts to fill them.

jlhonora 12y ago
Android's layout structure could be an option. It is much easier to handle than HTML + CSS, IMHO.
fidotron 12y ago
To be clear, I think in the medium to long term other than legacy HTML support browsers will get out of the layout engine business. Layout belongs in the JavaScript layer (or similar execution env) on top of a lower level abstraction, which is why I picked out WebGL as the most likely contender. Then the on the wire format becomes pure semantics, which can either be semi standardised, or not. (And Google clearly have an interest in promoting the former). WebGL, as it stands, seems to lack a few useful primitives for such a task, most notably needing an equivalent to process separated iframes. That might be possible already, but if not I'm sure it will be cracked enormously faster than attempting to debate and implement tiny incremental improvements in the HTML spec. My understanding is this is remarkably close to how the PS4 UI is actually implemented already.

marknutter 12y ago

> The web is now hamstrung by the HTML/CSS layout model more than anything else Really? Because I find it far more intuitive and flexible than working with xibs, for instance.

adamnemecek 12y ago
Well, xibs solve a bit more complex issue.
- marknutter 12y ago
  That being?
  - adamnemecek 12y ago
    I mean with Xib, you can e.g. specify how the window should behave when you are resizing it since you are specifying layout constraints as opposed to having to hardcode the layout. With CSS, your only recourse is media queries but those are a lot less fine-grained. Look into http://gridstylesheets.org http://gridstylesheets.org (and more specifically http://gridstylesheets.org/guides/ccss/ http://gridstylesheets.org/guides/ccss/) which is kinda the love child of CSS and Xib (or the technology that inspired the layout technology).
    - ggamecrazy 12y ago
      Are you talking about Auto Layout? You can write the same thing programmatically, in fact it's quite nice, though not as obvious as modifying frames.
      - adamnemecek 12y ago
        I was. But you are still hooking into the same layout API as if you'd use IB.
    - marknutter 12y ago
      I still don't understand why the issue is more complex for native mobile apps than it is for web mobile apps? Don't they all have to accommodate for the same screen sizes?

pjmlp 12y ago

Web was never meant for applications. Other hypertext models like Hypercard and Xerox PARC experiments had better support. I really hope that we can sort out this mess some day. I personally like apps are making the network more relevant than the Web. What matters are communication protocols.

sdegutis 12y ago
Who could fix it? What organization or individual could possibly create an architecture that all of the web could be ported to, that's better than our existing web? Especially considering we usually get pretty upset at companies for trying that.
- DanBC 12y ago
  You don't port "all of the web". You have apps that the Internet. You also have the WWW. People developing apps can chose whether to also develop for the WWW. Hopefully this would stop people doing stupid horrible things on WWW (forcing fonts; preventing zoom; etc) because all that hateful stuff can be done in their app and doesn't belong on WWW.
- malandrew 12y ago
  No one needs to "fix it". What we need is more safe low level primitives from the user agents, that allow many individuals and companies to explore building alternatives in the browser. Then from two or more approaches, some standard will eventually shake out through the standardization process. Most features we have in the web started with a feature in one web browser, that others copied and eventually became a standard. If the browsers exposed more low level features, more people could contribute ideas on how to "fix" the problem. Browsers should be written to expose APIs needed by the same people that write native applications today, but do so using a more appropriate trust and sandboxing model than what operating systems do. The browsers should act as "user agents" advocating on behalf of the users while exposing as low level and powerful APIs as possible and then standardizing those ideas that are well baked. edit: regarding low level primitives, this comment [0] in this thread by addyo (Addy Osmani) is relevant. This low-level work is crucial. [0] https://news.ycombinator.com/item?id=7917493 https://news.ycombinator.com/item?id=7917493

adamnemecek 12y ago

Indeed. I'm surprised that the whole Cassowary hasn't taken off. It's been around since '99. The fact that it hasn't is probably one of the worse is better 'typathingys'. http://en.wikipedia.org/wiki/Cassowary_(software) http://en.wikipedia.org/wiki/Cassowary_(software) https://www.cs.washington.edu/research/constraints/web/ccss-uwtr.pdf https://www.cs.washington.edu/research/constraints/web/ccss-...

agumonkey 12y ago
Didn't know it was the logic behind http://en.wikipedia.org/wiki/Scwm http://en.wikipedia.org/wiki/Scwm
adregan 12y ago
drewda's comment below[1] is an example of a JS library that implements Cassowary in the browser. It's called Grid Style Sheets. 1:https://news.ycombinator.com/item?id=7917646 https://news.ycombinator.com/item?id=7917646
- girvo 12y ago
  And it's awesome. Where I'm working we've embedded it into Node-WebKit for an app we're building ;)

drewda 12y ago

A partial bit of progress toward a better layout model: http://gridstylesheets.org/ http://gridstylesheets.org/

jacquesm 12y ago
If you make that page really narrow there is an ugly purple bar that comes into view from the left that overlaps a part of the content.

Jonovono 12y ago

Been following this project for awhile: http://www.nidium.com/ http://www.nidium.com/ . Hopefully they launch soon cause I am curious to try it out.

agumonkey 12y ago
I'm affraid they'll turn into vaporware.
malandrew 12y ago
I found these two bullet points truly odd "Yes, it's a kind of browser, and you can browse online webapps ... We do not support HTML & CSS". You don't need to throw HTML and CSS out wholesale (it still has uses) and you don't need to implement an entire browser to get many of the features listed on that page (except maybe the audio stuff). At famo.us [0], we're doing a lot of the things they say their final product will have but within the context of any modern web browser. [0] https://github.com/famous/famous https://github.com/famous/famous

agumonkey 12y ago

I'm personally waiting for distributed Self objects. When we cut the document presentation mindset maybe ...

yesimahuman 12y ago

Horrific is an exaggeration. You may not like it, but that doesn't mean it's overly difficult to build native mobile UIs with standard HTML and CSS. Also, Flexbox makes this even easier, and is a great step forward.

vlunkr 12y ago

I disagree, HTML/CSS have come a long ways in the past few years, in terms of browser compatibility and features. I don't see how introducing a new layout engine would help. That's just another standard that every platform has to support. Using WebGL would be great, but so far WebGL support on mobile is not great. If you haven't worked with web tools recently you should see how far they've come. With JS frameworks like Angular or Ember, and crazy fast build tools like Gulp, it's pretty nice developing for the web these days

rimantas 12y ago
> If you haven't worked with web tools recently you should > see how far they've come. And if you take a good look what native SDKs offer all that progress looks laughable.

lukifer 12y ago

In particular, the broken implementation of CSS position:fixed on all mobile platforms is probably the major stumbling block preventing app-like interfaces for the mobile web. I have been frequently tempted to try to build a canvas-based interface from scratch, but I suspect even that would run into the same problems.

_broody 12y ago
I think app-like interfaces on the web are a pipe dream at this point, anyways. Attempts to emulate native interfaces inevitably get stuck in a java-like uncanny valley that's nearly as hard to get out of as it would be rewriting native apps for each platform from scratch. For all the talk of web apps as credible alternative to native ones, the fact is the current toolchain is unlikely to ever be good for anything more than paper-thin clients. Ecmascript 6 doesn't fix this, Ecmascript 7 won't fix it. HTML5 tags are a worthless collection of semantic sugar when we desperately need a solid component library instead of implementing everything from scratch.
- simonw 12y ago
  "HTML5 tags are a worthless collection of semantic sugar when we desperately need a solid component library" What's your opinion of Web Components?
- lukifer 12y ago
  Agreed that a richer component library is badly needed. However, native apps can and do frequently invent new UI paradigms outside native (games in particular like to invent their own UIs, to varying degrees of success). Rather than poor imitations of native, I think web apps UIs would do well to draw their own cross-platform custom UI elements. I don't believe that interoperable and usable web apps are a mere pipe dream, on desktop or mobile; can you imagine a world in which the open web never took root, and we were all stuck on AOL, Compuserve, and Prodigy? That's the current app ecosystem in a nutshell, and it's deeply suboptimal for both users and developers.

protonfish 12y ago

This is the same complaining I always hear from people who don't want to learn how to use HTML and CSS. Yes, it is different than what you are used to. Yes, it will take some time to learn and some of that will be uncomfortable. But that does not mean that that HTML and CSS are bad. I know this because I successfully build mobile sites that look and function fine and I assure you it works. You say "hackery is required to attempt to imitate native mobile apps" and I agree with you. Can I ask why it is so important to copy the styling of native? That seems like a lot of effort for no good reason. Mobile web can be better than native if you let it, but forcing it to be something else purely for reasons of fashion is foolish. HTML/CSS produces a flexible layout that is usable by many different sizes and types of devices (even audio interfaces) and that is a good thing. It takes effort to get it working for all of the possible ways it could be used, but it is possible. After a little practice, it can even get easy. The hard parts of HTML/CSS would still exist in any flexible layout solution. Making a rigid screen-painted layout solution avoids problem inherent in flexible layouts those, but it gives up so much.

malandrew 12y ago
If you're not using HTML/CSS for documents then yes it is bad. It's fundamentally the wrong abstraction. I began my career with HTML and CSS and after seeing alternatives, there is no doubt in my mind that trying to build apps on HTML/CSS is fundamentally wrong. I'm not saying that there aren't a lot of good ideas introduced by the web (documents, hyperlinks, semantic metadata, responsive layouts, accessibility, URIs, etc.). What I'm saying is that there are good parts and there are bad parts, just like with native. What we need is a marriage of the good parts of the web with the good parts of native. We can do better. Much much much better.
- diminish 12y ago
  most of the development frameworks called native, are built on the precursor of html, namely 90s and earlier native app apis, on guis, and they arents perfect abstractions for apps neither. Current native zeitgeist gets its allure mostly from being closer to hardware and is the assembly to C. Otherwise all major mobile GUI APIs are naive attempts by busy developers to imitate, layouts, stylesheets,....

spitfire 12y ago

If we're throwing out HTML/CSS why on earth would you keep Javascript? (or also contentiously - HTTP) If we're throwing away the cruft (which I fully support!), lets do things right. That means planning a (light) abstraction layer for a world where you can use the right tool for the job.

malandrew 12y ago
Javascript is not the problem (though I think we would all be better off with more variety like NaCl would have provided). I'm actually starting to wonder if an approach like docker/lxc, but with web features ported to native land may not end up making more sense in the long term. The idea would be to take all the features of the web that aren't document focused and make them available in userland in a linux container. For example, the linux container would have to ask for permission from the host operating system to get GPS access or Contacts API access. It would also support the ability to use URIs to manage the state of any chromeless "window" object. It may be easier to take the web to sandboxed containers than bring all the operating systems concepts to the browsers. Basically this would be a LXC User Agent.
- walterbell 12y ago
  > It may be easier to take the web to sandboxed containers http://httplocal.com/ http://httplocal.com/ is working on local composition of web pipelines. Micro Xen (Bromium) forks a virtual machine with a fresh copy of the host operating system and browser for every URI. What do you think of iOS8 extensions and Android intents? Or https://sandstorm.io https://sandstorm.io ? The challenge is maintaining security and composition flexibility. Apple only opened up a few APIs.

malandrew 12y ago

I'm so happy that this comment is here and the top most voted comment. I keep making this point every time web apps come up. I still don't understand why the user agents still haven't started work on a retain-mode scene graph for the web that plays nicely with HTML when a document is needed. I really want a graphics system in the browser that can do the types of things being done here: https://news.ycombinator.com/item?id=7896773 https://news.ycombinator.com/item?id=7896773 i.e. Wayland for the Web with documents If we jump on this now, maybe we won't be left in the dust when native makes the jump from 2D to 3D and interface devices like the Oculus Rift go mainstream. This is probably 5+ years away, but now is the time to start considering how these capabilities will be possible at the lowest levels. None of this precludes the entire 2D web we're familiar with since 2D is simply an elevation view of 3D. Baking 3D in from the start leaves room for people to explore the possibilities people are exploring on native instead of being hamstrung by naïve technological choices. We're trying to explore what is possible here at famo.us [0]. Hopefully between what we're doing and what others are exploring, we'll come up with some interesting approaches that eventually made their way somehow to becoming a standard. The w3c spends too much time trying to expose APIs for the jQuery level developers instead of seeing the web as an operating system and exposing operating system primitives from day one. All they need to do differently from how previous operating systems worked is consider how the semantic web, accessibility, and URIs fit into this computing model. relevant: http://acko.net/blog/shadow-dom/ http://acko.net/blog/shadow-dom/ [0] http://famo.us/ http://famo.us/

d1plo1d 12y ago
Edit: just FF'd to the 3d cube bit.. nm. We can't do that without WebGL. That's what I get for not watching the entire video. Not sure what your getting at. The Wayland demo looks like it could be completely recreated with existing CSS3 3D transformations. Here's a similar example in a browser using HTML and CSS3. These transforms can be used on anything you can fit in a DOM element: https://www.webkit.org/blog-files/3d-transforms/morphing-cubes.html https://www.webkit.org/blog-files/3d-transforms/morphing-cub...
- malandrew 12y ago
  Not exactly. If you browse down that thread and read the dissertation and the accompanying slides, you see that that demo goes well beyond positioning a rectangle (texture) in 3D space (which we already do at famo.us). That guy went on to explore cuboids in addition to rectangles as a basic windowing primitive.

grey-area 12y ago

For the majority of web content today, HTML5 is actually surprisingly appropriate, if a little verbose. I'd contend it is also appropriate for most documents/data of the future too - WebGL is not required or suitable for most content (which is text/media based, not 3D models or animated shapes). Of course some widgets or effects might use GL behind the scenes, but the browser should insulate the users from that sort of thing, and GL is hardly a model API either. A raw JS and WebGL engine would be a creature of nightmares if you ask me! If you consider the content on a page of comments like this one, what improvements would a WebGL engine give you? The real pain points in the web of today speaking from a web developer perspective are CSS, JS and the DOM. It'd be nice to see the webkit browser makers get behind alternative style sheets, and alternative languages/APIs, because both CSS and the DOM have serious flaws and omissions which, while they are slowly being addressed, still cause a lot of pain. It'd be great if language creators could write plugins or compilers to see their language of choice as a sandboxed language available on the web, and see those bundled with browsers, and it'd be great if browser developers took a serious look at alternatives to CSS for layout - something much simpler could work so much better, and maybe we need different styling languages for different purposes (for apps or for documents for example). HTML is pretty flexible and people could always define fallback CSS for browsers that didn't support the new stylesheet variants. There's no reason browsers can't support a few languages with improved DOMs and a few styling languages. Sadly, I suspect we'll just see browsers bumble along adding some modules on CSS and improvements to JS instead. One of the big attractions for me about server-side development and HTML is that you can use whatever you like on the back end, as long as you feed the client HTML. It'd be lovely to see that sort of freedom to experiment extended to the front-end as well. If the web is to be an operating system, let it be an open one.

fred_durst 12y ago

When having these Native vs Other discussions, is it possible you could use something more specific than the word native? It means a lot of different things to a lot of different people. For example is declaring layouts in an XML file in an Android app considered native in this case? I've heard others say that Android apps that run on the Dalvik JVM should not be considered native. Maybe you are talking more about Cocoa or Windows?

pjmlp 12y ago
Native is whatever the operating system uses for user space applications. Android uses Java, C and C++ for user space applications, hence native Android means all three languages using Android APIs.
- deleted 12y ago
  [deleted]

LordHumungous 12y ago

Personally I'd rather use HTML/CSS than Android's xml (blech) layout syntax

deleted 12y ago

[deleted]

rl3 12y ago

>Google would be better off throwing efforts into a new layout engine leveraging raw JS and WebGL, but with a sane API, than these continuous attempts to push HTML into places where it doesn't work. WebGL is great when what you're trying to do simply can't be done in a high-performance manner using standardized markup. However, a generalist WebGL-powered UI framework would suffer the same drawbacks that Flash/Flex/Silverlight did: your content ceases being semantic. Of course, some sort of convoluted metadata system to preserve this could be devised, or simply run parallel to real markup that's not rendered, but those types of solutions are ugly at best. In my opinion, if you're going so far as WebGL to achieve UI performance in a mobile context, you should probably just make a native mobile app instead. At the moment, WebGL support on mobile tends to be incomplete and suffers from poor performance on most devices anyways. Mobile will always lag behind desktop in terms of browser performance and features, but browser optimization and mobile hardware is improving every day. Keep in mind that both desktop and mobile browsers already utilize GPU acceleration in some aspects of rendering normal content.

deleted 12y ago

[deleted]