It seems like this is more of a workflow than just a framework. Zurb and bootstrap don't come with build tools as far as I know, whereas this includes a gulpfile and a bunch of other stuff that's very common in my workflow. This feels more yeoman-esque + generator to me.
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.'
Yeah. that is a very good summary. If you want build process and tooling to help then we have that based on the tools that we think are the best, however we don't force workflow on people if they don't want it.
Paul Irish has given us guidance, input and feedback and is on the same team as me, but Addy Osmani is the main driver of starter kit, with me leading Web Fundamentals.
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.
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...
If it's just cleaning up CSS you're after, I would use UnCSS. Checkout grunt-uncss task or gulp-uncss to hook it up to your build process. We don't currently document using the tooling independent of the kit, but you should be able to pluck the package.json and gulpfile.js and edit per your needs. We'll try to get this documented.
We (speakerblast) created a wake lock solution that works in iOS6 & iOS7, as our web app syncs audio across devices.
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.
"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.
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.
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.
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.
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.
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.
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.
I mean with Xib, you can e.g. specify how the window should behave when you are resizing it since you are specifying layout constraints as opposed to having to hardcode the layout. With CSS, your only recourse is media queries but those are a lot less fine-grained. Look into http://gridstylesheets.org (and more specifically http://gridstylesheets.org/guides/ccss/) which is kinda the love child of CSS and Xib (or the technology that inspired the layout technology).
I still don't understand why the issue is more complex for native mobile apps than it is for web mobile apps? Don't they all have to accommodate for the same screen sizes?
Programming is all about abstraction management. Doing layouts with JS is using the wrong abstractions. CSS was originally conceived for doing document layouts but it's less suitable for web-application layout. We can leave the discussion here, if the article I posted didn't convince you, nothing probably will.
Well, I'm somewhat still arguing in the context of the OP's assertion that "the hackery required to attempt to imitate native mobile apps is horrific". I not only disagree that it's horrific, but actually think it's pretty darn good. I agree with you that it's not perfect, but perfect is the enemy of good.
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).
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.
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.
No one needs to "fix it". What we need is more safe low level primitives from the user agents, that allow many individuals and companies to explore building alternatives in the browser. Then from two or more approaches, some standard will eventually shake out through the standardization process. Most features we have in the web started with a feature in one web browser, that others copied and eventually became a standard. If the browsers exposed more low level features, more people could contribute ideas on how to "fix" the problem.
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).
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'.
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.
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
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.
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.
Agreed that a richer component library is badly needed. However, native apps can and do frequently invent new UI paradigms outside native (games in particular like to invent their own UIs, to varying degrees of success). Rather than poor imitations of native, I think web apps UIs would do well to draw their own cross-platform custom UI elements.
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.
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.
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.
most of the development frameworks called native, are built on the precursor of html, namely 90s and earlier native app apis, on guis, and they arents perfect abstractions for apps neither. Current native zeitgeist gets its allure mostly from being closer to hardware and is the assembly to C. Otherwise all major mobile GUI APIs are naive attempts by busy developers to imitate, layouts, stylesheets,....
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.
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.
What I meant, was initially people were pixel-painting fixed screens and 2D/3D graphic programming evolved as one branch, and GUI app frameworks evolved as another (MacApp anyone?). If you look at earlier Mac/Windows/X app frameworks and iOS/Android app frameworks, you'll see that the latter is a more naive and easy solution to the same problem without the burden of multiple docs, windows and massive multitasking. I'm talking about windows, views, user interface controls, dialogs, textboxes, styling and finally inputs (events). HTML/CSS/JS is a string based natural solution to the same problem.
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.
Developers that enjoyed access to Xerox PARC systems, RAD tooling, and environments like NeXTStep already had access to much better hypertext systems with layout support.
Do you have any good links/articles/discussions on these systems? I've read a bit about the origins of NeXTStep, but the work at PARC is something I know little about and RAD tooling is something completely new to me.
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.
The question is whether you start over or make incremental improvements. Supporting a new layout doesn't seem like the kind of change that's worth starting over for.
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.
I know your pain, vertically aligning anything in CSS is quite annoying, unless you have a fixed width outer container. That being said, that's a problem with CSS implementation as it pertains to this one particular problem. The fix isn't to chuck CSS and HTML, but to keep improving it.
I think the problem comes from a lack of understand of the complexity of such a task. Vertical align text according to what? The easiest way to vertical align text is exactly how you'd expect it to be, and it solves the problem perfectly.
If we're throwing out HTML/CSS why on earth would you keep Javascript? (or also contentiously - HTTP)
If we're throwing away the cruft (which I fully support!), lets do things right. That means planning a (light) abstraction layer for a world where you can use the right tool for the job.
Javascript is not the problem (though I think we would all be better off with more variety like NaCl would have provided).
I'm actually starting to wonder if an approach like docker/lxc, but with web features ported to native land may not end up making more sense in the long term.
The idea would be to take all the features of the web that aren't document focused and make them available in userland in a linux container. For example, the linux container would have to ask for permission from the host operating system to get GPS access or Contacts API access. It would also support the ability to use URIs to manage the state of any chromeless "window" object.
It may be easier to take the web to sandboxed containers than bring all the operating systems concepts to the browsers. Basically this would be a LXC User Agent.
> It may be easier to take the web to sandboxed containers
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'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.
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.
Not exactly. If you browse down that thread and read the dissertation and the accompanying slides, you see that that demo goes well beyond positioning a rectangle (texture) in 3D space (which we already do at famo.us).
That guy went on to explore cuboids in addition to rectangles as a basic windowing primitive.
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.
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?
>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.
I wondered if Google's internal development infrastructure looks like or hooks into Google Code, making it easy to release code publicly on Google Code.
Not really... it's about the same amount of work whether it goes to Google Code or GitHub. The teams that have an easier time of it are those that are using Git+Gerrit internally, since a public release is as simple as `git remote add` and `git push`. A number of teams continue to use tools like https://code.google.com/p/make-open-easy/ with varying degrees of success.
Which is a real shame because if they updated it properly they could be a real competitor to Github or Bitbucket and there's plenty of opportunities to add really simple integration to GAE or Compute.
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.
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?
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.
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.
>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.
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.
"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.
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.
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.
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.
One of the core values behind this project is that it should work extremely well cross-device and that most definitely means on devices where Chrome isn't the primary browser. During development we've ensured that we test on Firefox OS, Windows phone, iOS and browsers other than Chrome which run on Android. I want to give people something that they can rely on. Chrome isn't the only browser in the world for sure :)
I don't think he means locked into a single browser, I think he miiiight mean "generally locked into using a computer at the level of a browser vs. at the level of the OS." As in, "your mom and uncle will buy a web-browser, they won't buy a computer."
So understand I've got a bit of history here, back in the old days I was working on Java/HotJava and the whole applet thing. Netscape was doing their own thing with what would become known as Javascript. Our vision was "Gee everything that runs in Java can run anywhere, regardless of OS or device etc etc." its a great vision. In the nearly 20 years since since Java pushed out the door (March '95, best of times and worst of times :-) this has never worked. Not for Java, not for Javascript, not for C#, not anything. Certain browsers work, some don't, there are quirks everywhere.
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.
I think that to some degree the lack of certification for browsers (and ditto for Java runtimes back in the days) is what is causing this. Write-once-run-anywhere became Write-once-debug-everywhere.
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.
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:
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.
Like they say, there are no original ideas. At some point the W3C needs to give some serious thought as to how to do applications on the web the right way. That's roughly my wishlist for the future.
What prevents Chrome from running a simulator of Android, and web pages to embed an Android app that will execute, replacing the web page it came from?
That would be exactly like the Java applet, except with a much better API (and touchscreen laptops would finally make sense).
What the fuck? There is so much wrong with those two sentences, I'm not sure how you managed to string them together to sound like it describes something real.
I've seen many and worked on one in the late 90's that could out do any HTML5 app I've seen or written. We did it with cohesive API's of the caliber of Windows API but multi-platform and web transparent. Those who wrote off applets will not be looked upon favorably by history.
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.
So? If the Java applet was not proprietary, slow and crappy, and if Sun got GUIs and applications, it would be a good thing.
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.
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?
It is a very interesting question to ponder. If you see the web as a logical progression from email->newsgroups->gopher->www then clearly what was missing were the missing links. Once we had those everything else grew exponentially. But the web was clearly not intended to become an application platform. At the same time now that it has become an application platform we are facing a difficult choice: stick to incremental improvements and all kinds of hacks to shoehorn application interfaces into a document model (an awkward fit at best) or, alternatively to see where that progression could go next. How to preserve the 'link' feature and the advantages of the web while addressing the gap between native apps and web apps, improved user privacy and security, less reliance on verticals.
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].
[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.
- 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 think it's both good and bad in theory and both good and bad in practice. Certainly most of the things you list are major downsides, but none of them keep the upside from being (IMO more) major.
I'm you're right that the experience is "almost always" sub-par. I would say "often", but not even "usually". I guess YMMV.
> 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.
Google does in fact make a non-web version of Gmail. Gmail.app for iOS and the Android port of gmail. Both of which are a MUCH better experience them the comparable mobile web apps.
Apple's iWork suite is an example where someone is at least trying to make applications that run equally well within the browser, on mobile and on desktops.
But in practice it is much better than any alternative multi-platform instant software installation ecosystem. And in practice, it has led to a thriving ecosystem of applications, most of which can link to each other and will work on a large portion of users' devices.
The better way would have been for the open source community to advance the Linux desktop in the way that OSX has been evolved - i.e. To gradually bring the advantages of the web back to the OS.
Giving data to third parties is a side effect of networked applications, not web apps specifically. Whether the client is in a browser or a stand-alone native app, if you give it data, it will pass that data back to the application servers.
that the final experience is almost always sub-par.
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.
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!
The other way this illustrates a massive problem is the idea that we are supposed to be impressed by this functionality.
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.
What's the distinction? It also runs in Firefox yet the audio is out of sync (as of now). IE doesn't support the necessary tech needed.. Not yet at least.
Also the majority of mobile web users use safari and chrome anyway. Those two browsers to me are the mobile web.
Well, for starters, web applications without internet connectivity are, at best, an inferior experience. Secondly, web applications are inferior in terms of both user experience and performance in all but the most trivial applications. Thirdly, developing for the web is actually at least as much of a pain, if not more so, than supporting native code bases for multiple platforms. The difference is that webdevs have shifted that fragmentation from the native SDKs and APIs into the webdev versions of the same thing (JS frameworks, browser support, etc.).
>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 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.
Cross platform GUI widgets were possibly a good idea seven years ago if you didn't care about looking too good on OS X (still today, Qt applications look somewhat off on that platform). Today, they are a terrible idea, because every mobile platform looks different and if you try to make one interface for all, it will feel non-native on every one. At least if you use completely custom widgets, as HTML forces you to, it will be clearly non-native, not something pretending to be native but with the wrong behaviors.
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.
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.
"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."
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.
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...
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.
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?
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.
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.
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 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!
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.
216 comments
[ 4.5 ms ] story [ 237 ms ] threadEDIT: 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.
EDIT: adding link to issue tracker.
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.
[0] https://news.ycombinator.com/item?id=7917493
[0] http://extensiblewebmanifesto.org/
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-...
1:https://news.ycombinator.com/item?id=7917646
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
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
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.
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
http://www.youtube.com/watch?v=y43fI7Dy04A
http://www.youtube.com/watch?v=5QJTsPQQCCc
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.
http://jsfiddle.net/gJP9k/
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
What's the problem?.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.
I agree with @ceejayoz -- Google Code will be killed off ala Google Reader.
Can you file an issue on the github project so that we can work on it to see if it is an issue.
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!
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.
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...
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.
"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.
/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...
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.
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!