Web Starter Kit

https://developers.google.com/web/starter-kit/

by restlessdesign • 12 years ago

553 210 12 years ago

developers.google.com

dudus• 12 years ago

Twitter Bootstrap competitor?

Nico2706• 12 years ago

More like html5boilerplate alternative.

kinlan9• 12 years ago

I think this is a fair comparison. Right now we are not providing components like the ones you get in Zurb and Bootstrap.

EDIT: clarified.

Kiro• 12 years ago

Definitely more Bootstrap than H5BP. H5BP is just an index.html with some reset CSS and Modernizr. This is much more.

rog3r• 12 years ago

More like Yeoman competition.

addyo6• 12 years ago

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 of your application. We think this leads to a poorer experience. It's also easy to just end up with 100KB+ of styles (unless you're opting for a modular build) that never get removed.

In Web Starter Kit, we provide you a boilerplate set of base styles and a visual style guide for your components, but we actively encourage you to change these to suit your own app. This may require a little more work, but the reality is that any serious project is going to have it’s own look and feel and we want you to feel comfortable changing the kit to suit your own needs.

We also include tooling for removing unused CSS. So, even if you use our styles (or choose to use Bootstrap instead) we should hopefully help keep your pages lean.

joshma• 12 years ago

Is there any way to use the tooling independently of web starter kit? Wasn't able to find a link on the site, are they just warnings you see once you start developing? Can the tooling account for JS changes and navigation between pages?

Sorry for the barrage of questions, just really hoping to find a decent tool to clean up CSS...

paul79864• 12 years ago

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

Throwaway0812• 12 years ago

"it’s (almost too) easy to get stuck using their styles, look and feel for the lifetime of your application"

I'm a developer, and I've never used Bootstrap in my life, but my favorite aspect of Bootstrap is how it brings a sense of familiarity to the web. Why does every website need a unique look and feel? I'd rather not learn a new navigation or layout a hundred times each day. The internet is primarily about content, and Google should know that more than anyone. However, everyone tries to reinvent the wheel, and when I come across a Bootstrap site, it's somewhat comforting.

Don't get me wrong, creativity is important to some sites, and others are required to go outside of the box to reach their goals. However, they're the minority.

greenpizza13• 12 years ago

Feels like a Bootstrap competitor, with many more cross platform features and shortcuts to optimizations, device access, etc.

nullgeo• 12 years ago

Ironically the home page for it looks horrible in the latest version of Chrome under Windows.

kinlan9• 12 years ago

Can you file an issue on our repository and I will investigate it. It looked ok when I was running it last night. https://github.com/Google/WebFundamentals/issues is our tracker.

EDIT: adding link to issue tracker.

flipcoder• 12 years ago

Same here, with Firefox on Linux. The grid shows gaps like the web page is missing icons when you stretch the window width far enough.

graedus• 12 years ago

For me (Chrome, Win7), the gaps are explained by "PageSpeed Insights Reporting" and "SASS Support" wrapping down to the next row for all but a small range of horizontal viewport widths.

Siecje• 12 years ago

I wonder what browsers versions they are going to support at launch.

addyo6• 12 years ago

We cover this in our browser support section: https://github.com/google/web-starter-kit#browser-support

cozuya• 12 years ago

I'll be that guy: this seems nice, I'd love to use it, I'll take another look some time around 2018 when I can start to consider pitching dropping IE9 support. IE10+ is simply ridiculously prohibitive for something like this.

leke• 12 years ago

It's a good idea, but it's currently lacking the richness of bootstrap.

addyo6• 12 years ago

For sure. This is just a start and we don't intend on competing with Bootstrap in terms of UI components. We spent a long time evaluating many of the existing UI libraries available today and if a developer chooses to use one of them with the kit, they can. That's cool.

fidotron2• 12 years ago

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.

addyo6• 12 years 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/featur... for feature gaps and efforts to fill them.

jlhonora• 12 years ago

Android's layout structure could be an option. It is much easier to handle than HTML + CSS, IMHO.

fidotron2• 12 years 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.

marknutter5• 12 years 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.

adamnemecek6• 12 years ago

Well, xibs solve a bit more complex issue.

Tloewald• 12 years ago

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

pjmlp6• 12 years 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• 12 years 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.

simonw2• 12 years ago

"Web was never meant for applications"

And yet the web is a better platform for applications than anything else.

Zero installation, linkable states via URLs, universal back button support, accessibility hooks, multi-device, write-once-run-anywhere and an enormous variety of available programming languages.

All of that, AND it's built on top of truly open standards that aren't controlled by a single company and can't be killed by anyone (something VB6, Flash and BlackBerry developers should really appreciate).

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

agumonkey3• 12 years ago

Didn't know it was the logic behind http://en.wikipedia.org/wiki/Scwm

adregan• 12 years 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

drewda• 12 years ago

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

jacquesm9• 12 years 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• 12 years ago

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

agumonkey3• 12 years ago

I'm affraid they'll turn into vaporware.

malandrew11• 12 years 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

agumonkey3• 12 years ago

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

yesimahuman• 12 years 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• 12 years 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• 12 years 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.

lukifer2• 12 years 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• 12 years 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.

protonfish2• 12 years 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.

malandrew11• 12 years 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.

dminor• 12 years ago

After a little practice, it can even get easy.

Just googling for "vertical align text css" should be enough to tell you that different layout is needed. Why shouldn't there be a layout model that makes it easy to do the things people are trying to do?

The idea that we shouldn't even attempt to create a better one is silly.

BorisMelnik• 12 years ago

but forcing it to be something else purely for reasons of fashion is foolish.

its not fashion, it is UX, usability, and standardization

spitfire• 12 years 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.

malandrew11• 12 years 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.

malandrew11• 12 years 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

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/

[0] http://famo.us/

d1plo1d• 12 years 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-cub...

grey-area• 12 years 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• 12 years 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?

pjmlp6• 12 years 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.

LordHumungous• 12 years ago

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

rl3• 12 years 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.

ondrae• 12 years ago

Its interesting they are using GitHub instead of Google Code.

addyo6• 12 years ago

Google Code is great, but I personally love GitHub <3 We've been actively pushing to do more development there across https://github.com/google https://github.com/googlechrome and so on.

wldcordeiro2• 12 years ago

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

wuliwong• 12 years ago

It seems the navigation disappears entirely when you shrink the window. I would think they would implement their "hamburger" icon?

kinlan9• 12 years ago

Ah, cool I think you have hit an intended design feature. We use min-device-width to know that you started on a smaller screen (or a wide screen). If you are on a wide screen responsive elements are changed slightly to fit the screen. If you start on a small screen you get the hamburger menu.

Can you file an issue on the github project so that we can work on it to see if it is an issue.

OutThisLife• 12 years ago

On the homepage, the 'hamburger' menu doesn't show. Every other page is fine though.

gerbal• 12 years ago

On other pages it does hamburger icon properly, so, presumably, it's an issue with that page.

aikah• 12 years ago

@addy nice!

so what's the goal here.Why would one use this over bootstrap/foundation/x css framework?

Do you intend to integrate this with other frameworks you've written and other Google products like polymer/angularjs? My point is are you developping a coherent ecosystem or are they just independent tools?

thanks.

kinlan9• 12 years ago

I'll just reply because I know Addy is crazy busy. The goal is to give developers the education and tooling they need to do well out of the box by following all of our best practices straight away. In this case it can complement bootstrap and other frameworks because we are not building out a component library.

lvillani• 12 years ago

I wish I had this in my tool belt a few months ago when we began working on our web application. The core of our project can be reduced to something like web-starter-kit but we had to get there with many, many hours of hard-earned knowledge. I also like the leanness and cleanliness of web-starter-kit, it's really a nice collection of best-practices and pre-configured tools.

I will definitely incorporate some pieces into our existing project and use it as a base for our next ones.

Thanks guys!

JohnnyPython85• 12 years ago

If you are planning to do the same, spend time listing down all your UI elements and test whether the theme supports them.

This is all too important when evaluating a prefab Bootstrap theme. In the past when I have used Wrapbootstrap themes, I've been a few days in frustrated that something isn't working. Then when I dig into the asset files I realize that the theme was poorly written and I've been spinning my wheels for nothing. It's too bad so many themes look nice but simply aren't built the right way.

smrtinsert• 12 years ago

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.

ch0wn• 12 years ago

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.

nlh• 12 years ago

One reason not to use your method: Google's own guidelines. See:

https://developers.google.com/webmasters/smartphone-sites/de...

"Sites that use responsive web design, i.e. sites that serve all devices on the same set of URLs, with each URL serving the same HTML to all devices and using just CSS to change how the page is rendered on the device. This is Google's recommended configuration."

Generally I've found that when Google recommends something, their search algo prefers this too. I obviously don't have direct proof that it does, but if SEO matters I'd follow what they suggest.

kinlan9• 12 years ago

It's an interesting one. Adaptive serving is a reasonable solution when you are a large site and you can't wholesale merge your site in one go into a fully responsive solution. We find that Adaptive (i.e, server side detection of "mobile") leads to way more problems in the long term with maintenance, keeping up with new devices and also ensuring that you have all the correct canonical links etc in place to ensure that your "SEO" is still good.

Our guidance is responsive all the things...

xbryanx• 12 years ago

I was really hoping "Delete key friendly" meant that they weren't forcing Chrome to bind delete to the back function any longer.

paulirish• 12 years ago

Removing that has been attempted a few times and failed. I would love to see that shortcut removed myself too. :/

nguyenhimself• 12 years ago

I'm surprised more people don't know about this BackStop extension that does just that: https://chrome.google.com/webstore/detail/backstop/pidcjgldc...

jacquesm9• 12 years ago

This somehow reminds me of Inception. We have a perfectly functional computer, then we run a browser on it, we download a bunch of HTML, which in turn will download a whole slew of JavaScript in order to create the illusion of an application running natively that offers a subset of what the computer could offer. The only difference is that this web application supposedly runs on 'all devices' except that every web application is quite brittle once you try to actually run it on all devices. And forget about device access (though that is slowly getting a bit better).

The only plus I see in all this is that in the end we are now free of the API lock-in that OS vendors traditionally required, that we tend to take 'client-server' applications more or less for granted and that because it is server centric you don't have to bug your users to download the latest version every time you improve things (though as was pointed out in another thread, this is also a disadvantage, as a user you lose control and if the company goes out of business you could lose it all).

The web also roams much easier.

If we keep going like this for a little while then we're back where we started, with the graphics terminals from the 80's, (canvas is pretty close actually) only this time across the WAN instead of a lan and with the ability to hyperlink between applications.

ChuckMcM2• 12 years ago

You trade browser lock-in for OS lock-in. The original Internet Explorer strategy. Fundamentally it is a rent seeking strategy. When I noticed that Google was up to paying a billion dollars a quarter for traffic I realized that in some ways the gold leaf was falling off the piazza and revealing the the ugly plaster behind it. My guess is that the rent seeking here is in the form of directing search traffic in some way.

esolyt2• 12 years ago

Browser lock-in?

What makes you think web applications made with this kit work only in Chrome?

malandrew11• 12 years ago

Exactly. This all leads me to wonder if work can't be done to take the good web concepts and back port them to the operating system level, per the ideas I've briefly touched on in these two prior comments:

https://news.ycombinator.com/item?id=7917921 https://news.ycombinator.com/item?id=7891913

edit: the two drive-by downvoters are invited to elaborate on how this comment could be improved or what they disagree with so vehemently that this merited downmodding.

jacquesm9• 12 years ago

That almost reads as a re-invention of the java applet.

chillingeffect2• 12 years ago

downvoters might have been too busy to actually consider the depth of the concept.

I would just suggest that it sounds like what Win7 does underneath the surface with the thousands of real-time Registry operations.

That sounds bad, but I'm sure it's chaos because the operations all grew by accretion, not by selection, as your suggestion to backport good web concepts indicates.

so.... What are the most likely candidates? What's ready? JSON? WebGL? A SQL interface to the Registry?

ender7• 12 years ago

The shocking, unprecedented, world-changing difference that the web brings is that on the web all you have to do is click a link and your computer downloads, "installs", and runs a program. No manual installation necessary, no upgrades, no installers or wizards. No delay. This process is safe -- the page is sandboxed and can't interfere with the rest of your machine. And these things can be instantly shared! All I have to do is paste a bit of text to my friends and it turns into another clickable link that's only a touch away.

Engineers frequently undervalue this feature, especially considering the things that the web give up in order to achieve it. So yes, it's a pain in the ass to get that div to align correctly but in exchange you get to run instantly and almost everywhere [1].

Relevant: http://xkcd.com/1367/

[1] Depending on your target audience, old browsers might be a major problem (China), but the browser landscape is rapidly improving in terms of a minimum expected set of features.

jacquesm9• 12 years ago

That's the theory.

The practice is that

- you give your precious data to third parties

- that the safety problem now shifts from keeping your computer safe to keeping data in the hands of third parties safe (and this does not always play out in the way we would like, see codespaces for a recent example)

- that even the client side safety is a problem, the 'distribution advantages' have also been recognized widely by the blackhats.

- that we end up being tracked from here to Tokio and that the web is rapidly turning into a series of silos that try to have as little as possible to do with each other.

- that the final experience is almost always sub-par.

The theory is fantastic, but the practice leaves much to be desired.

paul79864• 12 years ago

Indeed and I don't understand why many other developers poo poo web applications vs native.

For example we have a web app that syncs audio on any device running safari or chrome. When we demo/ turn a crowd and their devices into a stereo..we just ask them to go to X URL.

They load it up in their device and the host hits play. The audience is not forced to download an app and do a few other steps. It's just load URL and bam everyone's devices become a stereo. Many other ideas in this space can occur.

The web and what you can do it with current day isn't as hobbled as many think!

J_Darnley• 12 years ago

So, which browser has a perfect sandbox for everything it does? I like the sound of it. I wonder why they don't employ those same skills to secure other software.

derengel• 12 years ago

for newbies like me this is just to great, cross device webdev can be a nightmare or this just to good to be true?

tdicola• 12 years ago

How does this compare to Yeoman, and is it meant to be a replacement? I thought Yeoman was made by some Google folks.

sinaa• 12 years ago

From the documentation:

"Web Starter Kit is inspired by Mobile HTML5 Boilerplate and Yeoman's generator-gulp-webapp, having taken input from contributors to both projects during development."

kinlan9• 12 years ago

It's not a replacement. My opinion on this as a stakeholder is that is meant for different audience that Yeoman serves. Ultimately we have produced a highly opinionated stack that developers can start with and customize as they like (or not if they don't want to). This lets developers who are experienced quickly start and manipulate it, and lets developers who don't know what a good workflow looks like be set up for success straight away. Yeoman on the other hand gives you complete control over how you want your project to be started and assumes that you know all the answers to the questions the generator poses.

I also like that Web Starter Kit is just a simple download that you can extract and be good to go with.

webXL3• 12 years ago

Is it just me, or do the fonts on that page look terrible on Windows?

/edit: looks like it's just "Roboto Condensed"

wyck• 12 years ago

No it's not just you, it's everyone using chrome windows, it a bug in their rendering engine that has been unfixed for years.

There are multiple easy ways to fix this (load order, re-rendering font, server config)..you would think a web starter kit would get the basics of fonts right...

The layout is also broken for the icon rows...

Example: http://i.imgur.com/8DCIsLw.jpg

zapt02• 12 years ago

Looks like the classes for the icons are way wrong, or they forgot a clear:both; somewhere which makes the rows cascade improperly.

jahewson• 12 years ago

It's not a bug, it's just how GDI ClearType renders text. It doesn't perform y-axis antialiasing so almost-horizontal curves look blocky. The solution is to use DirectWrite but Chrome hasn't made the jump yet.

krambs• 12 years ago

Chrome has finally fixed this. There is a flag for DirectWrite in the release version, but it's actually polished in Canary.

They are aiming for 37.

https://code.google.com/p/chromium/issues/detail?id=137692#c...

ejain• 12 years ago

I can't help but notice that the display of <ul> items is broken (current Firefix, 14pt min font size)...

nekitamo• 12 years ago

Same here!

PeterUstinox• 12 years ago

Will this become an official Yeoman generator?

gedrap• 12 years ago

Some people hate the idea of shifting everything to Web. Other people hate how unsuitable HTML5/CSS3 is for replicating native appearance.

But I think overall, it's a good middle ground. There will never be a perfect solution in the real world (where resources are limited, and companies are motivated to lock-in).

Web is not a perfect medium, it has it's disadvantages. Web apps were definitely not in mind when developing and designing Web. But on other hand, it works and it's proven, it's been here for a while. There are solid technologies supporting it (nginx, apache, programming languages with their frameworks). Some say why not native? For the reasons we shifted away from native. Could we improve current situation with native applications? Maybe. But it requires a major player to get involved (read: money and skill). Would they be motivated in pursuing something philosophically right and all, while current technologies generate a lot of money? Doubt so.

Yes, HTML and CSS were not meant to be used for mobile apps, mimicking native appearance. As an alternative, we can stick to vendor, and learn vendor specific stuff which doesn't share much in common, not even programming languages. Meanwhile HTML/CSS is something much more developers are familiar. It allows more developers to develop iOS/Android apps. Maybe we should just make it DRYier like we were doing with so many problems? At first, grid frameworks came for CSS layout, then Bootstrap. And in future bootstrap-which-gives-native-iOS/Android look will come? There must be something like that already. We could throw it all away and create some new API (some suggest JS + WebGL). But again. It requires major effort, major resources and current technologies are money machines. So why to stop?

Not everything can be perfect and correct in real world, with real constraints. Some people prove that wrong from time to time. Will someone do this time?

peter-row• 12 years ago

Just a stupid question ... what is it?

edit: Answered in other people's comments - it's somewhere between HTML5BoilerPlate and Bootstrap - a basic "hello world" bunch of HTML / SASS / js boilerplate code. This one has an emphasis on mobile.

bgruber• 12 years ago

as someone only casually familiar with node and and frontend dev generally, i'm curious about the instructions to install gulp and other things globally instead of local to the project. could someone illuminate the reasoning behind that? my thinking is that you're almost always better off doing things local to the project if possible.

rwhitman• 12 years ago

I guess it makes sense that the only library left to have in Google's web stack was an HTML/CSS framework. So now the circle is complete - you can run a website in Chrome on a Chromebook with a Starter Kit layout (all images as WebP of course) on top of AngularJS, running off a Go backend on App Engine.

drcode• 12 years ago

I like this tool in theory, but the inital web site for it sucks...

I was interested in learning about their "Live Browser Reloading" but was unable to learn more about it, as I ended up traveling through a Kafkaesque labyrinth of documentation pages.

Google guys/gals: Please keep working on this, but also make the website more friendly!

jebblue2• 12 years ago

This seems crude to me compared to my experiences with jQuery Mobile. This also affirms my belief that custom Android and iPhone development is going to go the way of the dinosaur. It's all about the web.

jfoster• 12 years ago

It's always interesting to see the flurry of Google releases in the month leading up to Google IO. My understanding is that projects hold out on releasing in the hopes of being included in the Google IO line-up, but release just prior to (or after) Google IO if they didn't end up making the cut. I don't mean to belittle these projects (this one looks quite good, for example!), just pointing out that you can potentially get a read of Google's current priorities by comparing the projects released surrounding Google IO versus the projects released at Google IO. There are some other factors to be mindful of, such as Google IO's focus on developers, however.

mythz• 12 years ago

Why does this need to depend on Ruby as well as node.js? As a starter kit shouldn't it aim for the least dependencies to get started?

So for devs who want to use this with another web framework like Python, They need to have node, Ruby and Python installed?

Node is extremely easy to deploy/install that's even self-hostable where you can even check in node.exe (e.g. on Windows) into the repo so no prior installation is necessary. Just run `node install` to pull in all the dependencies and your away. Surely that's the kind of dev experience we should be aiming for?

Are the benefits for SASS over a pure js solution like less that much better to justify the extra infrastructure dependencies?

oliyoung• 12 years ago

Ruby is a dependency for SASS, that'd be the only reason

StillBored• 12 years ago

There is libsass and sassc https://github.com/sass/sassc

It works for a fairly large project i'm involved in.

Besides being AFAIU significantly faster then the ruby one, it allowed me to continue to refuse to add another scripting environment to our already mile long dependency list.

redact207• 12 years ago

I've been working on a similar web builder with Entomic - https://www.entomic.com - that lets you create sites and get live previews across different browsers and devices as you develop. It's a little rough still, but it does make responsive development a bit easier.

thinkerer• 12 years ago

I think if this can be extended to make the changes easy to apply (with real time checking of how the output will be) and understanding the code differences, then many of the wireframe companies out there may lose their appeal....

sidcool2• 12 years ago

I am a bit confused here. What is the difference between Dart and Angular, and this initiative? I hope this does not sound as a dumb question. I am asking this because people here are comparing it to Twitter Bootstrap.

spankalee• 12 years ago

Dart is a programming language that compiles to JavaScript. The project also encompasses APIs like collections, async and a much improved DOM API. Dart also has a node.js-like server VM with IO.

Angular is a client-side web framework that provides templating and data-binding. It was originally written in JavaScript, and now has a Dart port as well.

Somewhat relatedly, Google and Mozilla have been working on the web components standards, which bring some of the features Angular popularized, and some more fundamental ones as well, natively into the browser. These include Custom Elements, Shadow DOM, Mutation Observers, Object.observe(), and HTML Imports.

Polymer is a project that helps with building custom elements, it adds some sugar including templating and data-binding, similar to Angular in some ways, but completely focused on modern Web Components related standards, and on elements - not apps or frameworks. You can use Polymer elements in any app with any framework, or without a framework.

Web Starter Kit looks like a bundle tools to help you build a site with modern best practices, like responsive layouts, a local dev server, a build system, mobile-friendly user input, multi-device testing, etc.

Web Starter Kit looks like it's framework agnostic, so you could probably use Angular or other frameworks to fill in the views, though these days you might find you don't really need a framework if you're using Web Components.

sidcool2• 12 years ago

That's a comprehensive explanation, thanks!

bzelip• 12 years ago

Here's an informative podcast by the Changelog that interviews a Dart author and a Dart outreach advocate, http://thechangelog.com/121/

tldr; it's more than compiling to JS.

irfan• 12 years ago

This is how their homepage appear in my chrome:

http://i.imgur.com/UCfMstr.png

thomasfl• 12 years ago

That's it. Google now finally owns the web. The decide what people should find on the web, and they define the web standards, so why not use their html templates.

moretti• 12 years ago

I'm curios about the CSS naming conventions.

I'm assuming for example that component--modifier-name denotes a class modifier (ex. .button--primary and .button--secondary) and component__descendant-name denotes a a descendent node of a component (ex articles-list__item).

It looks similar to SuitCSS (https://github.com/suitcss/suit/blob/master/doc/naming-conve...). Is there more information about them?

xtx23• 12 years ago

isn't this just mostly a copy of Prepros: http://alphapixels.com/prepros/ :/

Web Starter Kit

Related Stories