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

61–70 of 218 posts

Re: Web Starter Kit

#61

Post by mofle »

paul7986 wrote: post #28
addyo wrote: post #10

Earlier quoted context omitted.

Good question. We don't consider ourselves a Bootstrap competitor, but rather a combination of best practices and tooling when it comes to starting work on new multi-device/mobile web projects. Bootstrap, Zurb and similar libraries provide a great start for prototyping your apps, but one of the biggest challenges with them is that it’s (almost too) easy to get stuck using their styles, look and feel for the lifetime…

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

Re: Web Starter Kit

#62

Post by malandrew »

spitfire wrote: post #50
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…

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.

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.

Re: Web Starter Kit

#63

Post by nacs »

ceejayoz wrote: post #42
wldcordeiro wrote: post #34

Earlier quoted context omitted.

Google Code has been languishing. You guys could really do some things with it to make it a competitor with Github and Bitbucket.

I see Google Code being in the same spot as Google Reader on Google's roadmap.

@hobofan: I think it's because they don't have any other choice when it comes to a public repo they can throw things up on.

I agree with @ceejayoz -- Google Code will be killed off ala Google Reader.

Re: Web Starter Kit

#64

Post by adamnemecek »

ggamecrazy wrote: post #56
adamnemecek wrote: post #44

Earlier quoted context omitted.

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 (and more specifically http://gridstylesheets.org/guides/ccss/ ) which is kinda the love child of CSS and Xib (or the…

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.

I was. But you are still hooking into the same layout API as if you'd use IB.

Re: Web Starter Kit

#65

Post by grey-area »

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…

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.

Re: Web Starter Kit

#66

Post by Tloewald »

marknutter wrote: post #16
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…

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

HTML/CSS aspires to being as flexible (and intuitive) as xibs. What do you think flexbox (coming real soon now, almost there, you can use it in IE11...) is? It's basically the view model that xibs have supported since 1989 (or whenever it was NeXTStep first shipped).

Re: Web Starter Kit

#67

Post by adamnemecek »

marknutter wrote: post #60
adamnemecek wrote: post #44

Earlier quoted context omitted.

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 (and more specifically http://gridstylesheets.org/guides/ccss/ ) which is kinda the love child of CSS and Xib (or the…

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.

Re: Web Starter Kit

#68

Post by smrtinsert »

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.

Re: Web Starter Kit

#69

Post by davb »

hobofan wrote: post #53
ceejayoz wrote: post #42

Earlier quoted context omitted.

I see Google Code being in the same spot as Google Reader on Google's roadmap.

I always begin to think the same thing, but then they open source a new project that is hosted on Google Code.

I wondered if Google's internal development infrastructure looks like or hooks into Google Code, making it easy to release code publicly on Google Code.

Re: Web Starter Kit

#70

Post by malandrew »

Jonovono wrote: post #36
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…

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

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

Post reply on HN