Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Starter Kit

developers.google.com

Post reply on HN
Print view View original

71–80 of 218 posts

Re: Web Starter Kit

#71

Post by diminish »

malandrew wrote: post #59
protonfish wrote: post #49

Earlier quoted context omitted.

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 require…

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…

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,....

Re: Web Starter Kit

#72

Post by malandrew »

diminish wrote: post #71
malandrew wrote: post #59

Earlier quoted context omitted.

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…

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,....

    "precursor of html"
please elaborate.

HTML is based on XML, a language with two primitives, strings and children. Why would you ever use that as an interface if you want something to ever be performant?

What we need is a retain-mode scene graph, where some of the nodes on the scene graph can be HTML documents (with URIs).

Developers don't want a one-to-one relationship between the window object and documents. They instead want a one-to-many relationship. The tag is proof of this.

Take Twitter for example. What is each tweet, but a 140-character document? The application for displaying an infinite list of tweets is not a document, but a multi-document viewer. The Facebook feed is the same thing.

If anything, this would prevent the shenanigans of blocking viewport resizing, because the user could choose an HTML document node on the scene graph and decide to make it full screen (the same way twitter allows you to click on a time stamp to get a permalink)

This retain-mode scene graph would need to support URIs so that you could always link to a subgraph of the scene graph and only view that part.

Re: Web Starter Kit

#73

Post by adregan »

adamnemecek wrote: post #26
fidotron wrote: post #13

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…

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) https://www.cs.washington.edu/research/constraints/web/ccss-...

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

Re: Web Starter Kit

#74

Post by paul7986 »

mofle wrote: post #61
paul7986 wrote: post #28

Earlier quoted context omitted.

I'm curious about the cross device synchronization. Can you provide further details on this and how it's useful when web apps can not keep devices awake (i.e. iOS8).

You can read more about the device sync solution BrowserSync here: http://browsersync.io/ As for keeping devices awake, that was actually recently discussed at specifiction: http://discourse.specifiction.org/t/allow-developers-to-cont...

We (speakerblast) created a wake lock solution that works in iOS6 & iOS7, as our web app syncs audio across devices.

In iOS8 as of now audio playback in Safari stops when the devices sleeps and or when the user exits Safari. This is not how it was previously, rather audio played in the background and audio playback kept the device in a semi wake stage.

Were hoping this is a bug they'll fix before the final and not the new way forward.

Re: Web Starter Kit

#75

Post by ch0wn »

smrtinsert wrote: post #68

I suppose you could go this route. More realistic is to produce different server side files for each client type and keep it simple. There are tons of business reasons to make them physically separate as well, special promotions, advertising requirements, conditional scripts, etc.

And there are also tons of reasons for the responsive solution. It all depends on your requirements and use cases. I don't think there's way to unconditionally say that one is better than the other at the moment.

Re: Web Starter Kit

#76

Post by d1plo1d »

malandrew wrote: post #51
fidotron wrote: post #13

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…

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/it…

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-cub...

Re: Web Starter Kit

#77

Post by dragonwriter »

malandrew wrote: post #72
diminish wrote: post #71

Earlier quoted context omitted.

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,....

"precursor of html" please elaborate. HTML is based on XML, a language with two primitives, strings and children. Why would you ever use that as an interface if you want something to ever be performant? What we need is a retain-mode scene graph, where some of the nodes on the scene graph can be HTML documents (with URIs). Developers don't want a one-to-one relationship between the window object and documents. They in…

> HTML is based on XML

No, its not.

HTML is based on SGML (it was originally an SGML application profile, though as of HTML5 it is no longer.)

XML was invented after HMTL, was inspired by HTML, and is also an SGML application profile.

So, insofar as XML and HTML are related all, its closer to the reverse of the relationship you describe.

Re: Web Starter Kit

#78

Post by malandrew »

d1plo1d wrote: post #76
malandrew wrote: post #51

Earlier quoted context omitted.

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/it…

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…

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.

Re: Web Starter Kit

#79

Post by marknutter »

adamnemecek wrote: post #67
marknutter wrote: post #60

Earlier quoted context omitted.

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?

It's not that it's more complex, it's that you can do things with native layouts that you'd have to use JS to achieve on mobile.

Good thing browsers run JS, eh?

Re: Web Starter Kit

#80

Post by malandrew »

dragonwriter wrote: post #77
malandrew wrote: post #72

Earlier quoted context omitted.

"precursor of html" please elaborate. HTML is based on XML, a language with two primitives, strings and children. Why would you ever use that as an interface if you want something to ever be performant? What we need is a retain-mode scene graph, where some of the nodes on the scene graph can be HTML documents (with URIs). Developers don't want a one-to-one relationship between the window object and documents. They in…

> HTML is based on XML No, its not. HTML is based on SGML (it was originally an SGML application profile, though as of HTML5 it is no longer.) XML was invented after HMTL, was inspired by HTML, and is also an SGML application profile. So, insofar as XML and HTML are related all, its closer to the reverse of the relationship you describe.

Thanks for the history lesson.

My point about strings and children still stand though. SGML is a document markup language. It was never designed for complex scene graph work, so I don't get how the OP I responded to came to the conclusion that HTML derived from anything that was originally used for things like applications and GUIs.

Post reply on HN