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.
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.
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.
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.
its not fashion, it is UX, usability, and standardization
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...
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.
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.
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.
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).
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://en.wikipedia.org/wiki/Cassowary_(software) https://www.cs.washington.edu/research/constraints/web/ccss-...
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.
Also, Flexbox makes this even easier, and is a great step forward.
Android uses Java, C and C++ for user space applications, hence native Android means all three languages using Android APIs.
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.
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.
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.
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.
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.
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!
What makes you think web applications made with this kit work only in Chrome?
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.
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?
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.
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.
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).
EDIT: clarified.
/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...
Can you file an issue on the github project so that we can work on it to see if it is an issue.
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.
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.
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.
"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.
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 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.
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.
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!
