Web Starter Kit
developers.google.com
developers.google.com
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.
What makes you think web applications made with this kit work only in Chrome?
Correct me if I'm wrong :)
"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"
The discussion here is about APIs that are specific to Apple, Microsoft, Google etc.
The default defensive strategy is to pick one browser you know work and select that as the 'standard.'
Not complaining just noting the lock in is an emergent property.
Java seems to finally start to deliver on this promise though, the last few years have seen quite a bit of improvement. (Still far from perfect though, just the other day I was fighting some corporate website that insisted I install a certain version of Java in a certain browser in order to be allowed access, and it crashed in terrible ways when I finally did gain access).
Imagine that your browser simply wouldn't be allowed on the web until it conformed to a standard. Just like cars aren't allowed to go on the road if they do not conform.
This is unlikely to ever happen for various reasons and I don't think it would be a good thing but the number of broken implementations and hacks-that-became-standards is too large to even count by now.
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.
That would be exactly like the Java applet, except with a much better API (and touchscreen laptops would finally make sense).
As usually with interesting ideas someone beat you to it:
http://www.appcelerator.com/blog/2014/01/browser-based-emula...
I wrote a powerful database GUI as an applet, to pick up an update all the user had to do was save their work and hit the refresh button. I used Symantec Visual Cafe.
And none of the above are necessary elements of a reinvention.
In fact, it's the current web one-page-app mess that is a re-invention of the notion of the Java applet warts and all: it's slow, has crappy GUI support, and it's a mess to develop in (like Swing was over-engineered crap).
We could use an actual sandboxed, "runs code from internet resources" platform, that contains the whole stack rethought and simplified.
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?
That's a very tough nut to crack.
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.
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.
I'm you're right that the experience is "almost always" sub-par. I would say "often", but not even "usually". I guess YMMV.
There aren't actually many fair/accurate comparisons around since most companies have either a shrink-wrapped product or a webapp. Rarely do you see both, and when there are I agree with jacquesm that the experience is almost always sub-par on the webapp [in comparison to the desktop app].
You can't really compare one company's webapp to another's non-webapp. i.e. you may feel GMail is better than Outlook, but since Google doesn't make a non-webapp version of GMail we don't know if that would be better than both Outlook and gmail.com. Microsoft does make a webapp version of Outlook, but I don't think many people find that better than "real" Outlook.
Ok... What is more fantastic for:
- large audiences?
- users who can't install/update software?
- " " can't/don't back up data?
- developers who don't have the resources to target multiple devices/platforms?
- integrations with other applications?
We're clearly in 'we should be amazed the pig dances at all' territory rather than in 'look how good the pig can dance'.
I have a Gmail account and a work one that is on Thunderbird. Gmail's through the web is just overall better than Thunderbird and I usually get people to send work stuff to my Gmail account.
But I don't hear many people talk about trying to improve it like some others are doing with remotestorage.io and byoFS or Mylar.
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!
That's not a web-app thats a 'safari or chrome' app.
This is more or less a perfect illustration of the the issue at hand here.
I'm not speaking specifically of the functionality that the grandparent poster used in his example, but just the general idea, for example: "Look at this classic console emulator, running in a webpage! (At 80% of the speed it would have run on a circa-1990s 90 mhz Pentium if it were a a native app!)"
To be clear, it is impressive when people create such things given the constraints, but (even ignoring the fragile compatibility problem between different browsers) when the platform you are using makes doing something that was impressive almost 20 years ago impressive (again) today, I'm not sure that's something we should all be that proud of as an industry.
Also the majority of mobile web users use safari and chrome anyway. Those two browsers to me are the mobile web.
It's not as fast or as smooth or as fluid as a native experience.
It comes close, but there is a always a slight, yet perceptible lag.
In addition, each platform has specific strengths - and the LCD of web-enabled means that they can't be used.
The same thing could happen with any sandboxed platform that allows code download from an internet resource -- even Java did it more than a decade ago (WebStart I think it was called).
For some reason (traction I guess) we did it through piling up of more and more BS into the web model (meant for documents), and leading into the current mess.
I mean, instead of the big guys (W3C style) getting together and creating a cross-platform sandboxed platform for native style apps (e.g with actual rich GUI widgets instead of just text entry boxes and text-boxes).
The irony is that each of the big guys developed a kind of its own half-arsed version of that, e.g Microsoft and XAML, QT and it's XML/JS thing, Adobe and Flex, etc etc.
I'm sure many people fundamentally want programming to be as close to write-once-run-anywhere as possible, and hence think this is a terrible state of affairs; for me, though, having different platforms with different, clear design philosophies is a good thing as it encourages people to care about and innovate in design.
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.
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.
Really? Because I find it far more intuitive and flexible than working with xibs, for instance.
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.
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.
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.
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).
Please lets not pretend the Web invented how to write portable code.
http://en.wikipedia.org/wiki/Cassowary_(software) https://www.cs.washington.edu/research/constraints/web/ccss-...
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.
Also, Flexbox makes this even easier, and is a great step forward.
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
> If you haven't worked with web tools recently you should
> see how far they've come.
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.
What's your opinion of Web Components?
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.
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.
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.
"precursor of html"
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 <article> 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.
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.
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.
Finally, current native programming does not get its power from any advanced technique or technology but only due to its privileged position in an underpowered computing device with a smaller screens and newer touch input methods and hardware. This way, mobile GUI API designers didn't have most of the problems of large screen OS framework API designers had. When I look at their APIs, they are too simple, nothing fundamentally new.
So as mobile devices get better in general computing, a post html world may come back, with stringified description of UI elements.
Xerox Star User Interface http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=ODZBL80JPqw
Tektronix 4404 Smalltalk http://www.youtube.com/watch?v=8yxCJfayW-8
The Smalltalk-80 Programming System http://www.youtube.com/watch?v=JLPiMl8XUKU
The Final Demonstration of the Xerox 'Star' computer http://www.youtube.com/watch?v=_OwG_rQ_Hqw
Symbolics Hypertext Document http://www.youtube.com/watch?v=7DxYj32cvoE
Warren Teitelman work at Xerox PARC https://news.ycombinator.com/item?id=7579613
The Mesa/Cedar programming environment https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fbitsavers....
Steve Jobs internal demo of NeXTSTEP 3, http://www.youtube.com/watch?v=gveTy4EmNyk
Alan Kay on Xerox PARC work
http://www.youtube.com/watch?v=0oonXT-gYjU
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.
That said, I'm all for experimenting.
There you go. That CSS is useful for popup dialogs. Though most of the difficulties I see with vertical-alignment are due to poor design and implementation.
HTML and CSS get new features all the time so clearly nobody is saying they shouldn't improve. It's people saying that "HTML is inherently broken so there should be something else but they don't know what" that I am getting sick of.
If you want to align text vertically, you just do
font-size: 20px;
line-height: 40px;
vertical-align: middle;
.vertical-text { display: flex; flex-direction: column; justify-content: center; }
(add ´align-items: center´for horizontal center)
its not fashion, it is UX, usability, and standardization
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.
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.
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 ? The challenge is maintaining security and composition flexibility. Apple only opened up a few APIs.
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/
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...
That guy went on to explore cuboids in addition to rectangles as a basic windowing primitive.
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.
Android uses Java, C and C++ for user space applications, hence native Android means all three languages using Android APIs.
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.
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?
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.
I will definitely incorporate some pieces into our existing project and use it as a base for our next ones.
Thanks guys!
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?
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.
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.
I agree with @ceejayoz -- Google Code will be killed off ala Google Reader.
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.
Can you file an issue on the github project so that we can work on it to see if it is an issue.
/edit: looks like it's just "Roboto Condensed"
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
They are aiming for 37.
https://code.google.com/p/chromium/issues/detail?id=137692#c...
"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."
I also like that Web Starter Kit is just a simple download that you can extract and be good to go with.
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.
tldr; it's more than compiling to JS.
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?
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!
There are tons of business reasons to make them physically separate as well, special promotions, advertising requirements, conditional scripts, etc.
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.
Our guidance is responsive all the things...
EDIT: adding link to issue tracker.
EDIT: clarified.
Edit: Totally posted this before I read '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. Our FAQs attempt to answer commonly asked questions about the project.'
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.
Sorry for the barrage of questions, just really hoping to find a decent tool to clean up CSS...
Can you provide further details on this and how it's useful when web apps can not keep devices awake (i.e. iOS8).
As for keeping devices awake, that was actually recently discussed at specifiction: http://discourse.specifiction.org/t/allow-developers-to-cont...
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.
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.