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).<p>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 <i>also</i> a disadvantage, as a user you lose control and if the company goes out of business you could lose it all).<p>The web also roams much easier.<p>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.
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.<p>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.
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?<p>So for devs who want to use this with another web framework like Python, They need to have node, Ruby and Python installed?<p>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?<p>Are the benefits for SASS over a pure js solution like less that much better to justify the extra infrastructure dependencies?
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.<p>I will definitely incorporate some pieces into our existing project and use it as a base for our next ones.<p>Thanks guys!
Some people hate the idea of shifting everything to Web. Other people hate how unsuitable HTML5/CSS3 is for replicating native appearance.<p>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).<p>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.<p>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?<p>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?
Just a stupid question ... what is it?<p>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.
@addy nice!<p>so what's the goal here.Why would one use this over bootstrap/foundation/x css framework?<p>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?<p>thanks.
>If you are planning to do the same, spend time listing down all your UI elements and test whether the theme supports them.<p>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.
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.
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.
I'm curios about the CSS naming conventions.<p>I'm assuming for example that <i>component--modifier-name</i> denotes a class modifier (ex. <i>.button--primary</i> and <i>.button--secondary</i>) and <i>component__descendant-name</i> denotes a a descendent node of a component (ex <i>articles-list__item</i>).<p>It looks similar to SuitCSS (<a href="https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md" rel="nofollow">https://github.com/suitcss/suit/blob/master/doc/naming-conve...</a>).
Is there more information about them?
I've been working on a similar web builder with Entomic - <a href="https://www.entomic.com" rel="nofollow">https://www.entomic.com</a> - 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.
I like this tool in theory, but the inital web site for it sucks...<p>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.<p>Google guys/gals: Please keep working on this, but also make the website more friendly!
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.
I suppose you could go this route. More realistic is to produce different server side files for each client type and keep it simple.<p>There are tons of business reasons to make them physically separate as well, special promotions, advertising requirements, conditional scripts, etc.
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....
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.
This is how their homepage appear in my chrome:<p><a href="http://i.imgur.com/UCfMstr.png" rel="nofollow">http://i.imgur.com/UCfMstr.png</a>
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.
isn't this just mostly a copy of Prepros: <a href="http://alphapixels.com/prepros/" rel="nofollow">http://alphapixels.com/prepros/</a> :/
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.