Related
I was wondering that if I want to make apps for both iOS as well as Android is it worth it to get into learning the whole HTML-CSS-JavaScript route or should I learn their native SDKs?
Exactly how much will HTML5 be the future I guess Im wondering. Is it going to really replace the native mobile app?
I know noone has a crystal ball but Im just seeking input from more experienced/or more senior developers.
Much appreciated.
The reality is that HTML5 will never be a realistic replacement for native applications built in iOS and Android, as it is not powerful or robust enough to do so. Additionally, using HTML5 will only work for you if you intend to create very simple apps. Even then, you will run into problems.
Consider for example the Table view in iOS. It can be highly optimized for speed and interaction in a way that will always surpass a third-party, remote solution such as HTML5. Note that the table view is one of the simplest things you will do when creating an iOS app.
Additionally, knowing Java (Android) and Objective-C (iOS) will be beneficial to you in the long run in terms of your development career.
There is one real exception: if your app is going to be the native representation of a web app (ie. Facebook) then it does in fact make sense to go with a largely web approach (HTML5/Javascript/CSS). In fact, that is exactly what Facebook did. However, even Facebook experienced a very buggy and crash-prone existence on mobile devices for the better part of a year.
In conclusion, I know of no application developer who seriously considers HTML5 as a contender for the building of mobile applications (other than for heavily web-based apps with web-like functionality). The dream, of course, is that HTML5 will be a "silver bullet" or a "golden hammer" for developers, ushering in a brave new age in which we are able to focus on learning one set of technologies for all sorts of devices. Unfortunately, it is merely a dream. At least for now.
In most desktop web applications I've ever worked on you need a server-side web framework. The server-side web framework (Struts, Spring MVC, etc) has some kind of controller for processing requests and then a templating engine (Velocity, JSP, etc) for generating dynamic content.
Now I am starting to work on mobile web applications and all the discussions I see revolve around selecting a UI framework (jQuery Mobile, jQTouch, Sencha Touch, etc) but I don't see any discussion of what is happening on the server-side to actually process HTTP requests or to generate the HTML, CSS, and JavaScript.
Does this mean that most mobile web applications do not use a server-side web framework... meaning the server serves static content, the majority of the interactive behavior is coded in JavaScript, and the only server-side code is REST services that the JavaScript client loads?
If I wanted to use a server-side web framework would that be a bad idea? What problems would I face? Does anyone have a recommendation on web framework that would be a productive platform and not "get in the way" of mobile UI frameworks like jQuery mobile?
NOTE: The developers I work with mostly come from enterprise Java backgrounds, however, I wouldn't limit it to only Java-based web framoworks. There are other frameworks out there that have roots in Java that could be considered (Grails, Lift, etc).
A good question for sure and I will answer it this way. The current trend is to build a lot of interactivity into the front end. There are several reasons for this. Some do it because it's the new thing to do, others do it because they're trying to replicate the desktop experience. In the end, there is only one goal for any given web project and that is to create Best and Most Sustainable User Experience.
That being said, there would be server side technologies to avoid and that would be any of that generate the front end for you but are not using jQuery. Over 45% of all websites today use jQuery and if you select something else, you will be instantly at odds with the prevailing mobile frameworks. (GWT, IceFaces, I'm looking at you).
Probably the safest and most flexible way to go would either be using a Spring based implementation or Prime Faces. Spring Mobile is worth looking at. Prime Faces actually implements jQuery Mobile and is theme-able using Theme Roller.
In general, it really doesn't matter what backend framework (if any) that you use so long as you're pushing good markup. The browser doesn't care and the only thing that user's care about is a good experience. So, pick whatever will make your devs happy for the backend so long as it doesn't get in the way.
As for front end frameworks, yes, their popularity is increasing because they do tend to standardize some of the best practices in mobile. There are many many comparisons of jQuery Mobile vs Sencha vs jQTouch. I'll leave you to figure which is best for your project but would certainly use either jQuery Mobile or Sencha because the community of support around these is massive and you're less likely to look like the many shabby, home-grown mobile sites that tried to do it from scratch when they didn't have the experience to pull it off. It's just sad. My personal recommendation is jQuery Mobile because it's covers such a wide range of devices and (provided you stick to the standard page-by-page model) will degrade gracefully for even the crappiest of feature phones and still be functional but look amazing on smartphones.
To your question of just using a RESTful design with JavaScript loading everything and managing state. There are many that are doing that and it's certainly a snappy experience but you'll be instantly limiting who can use it to people who's mobile browsers support good JavaScript. You'll be looking at only supporting iOS, Android 2.2+, BlackBerry 6+, and Windows Phone 7+. All others will likely have significant difficulty viewing your site. Carefully consider your audience before moving to an implementation like that. If your site wont work without JavaScript and your primary clients are in the corporate world... what happens when the latest Black Hat conference exposes a weakness in the company phones and out of conservative risk mitigation (paranoia), they push a security policy to everyone's phones that disables JavaScript. This kind of thing happens all the time. So, consider your audience.
Take a look to ItsNat, ItsNat invites you to think in client JavaScript but coding in Java and executed in server generating the same JS code to the client.
The difference with GWT is, Java W3C DOM code is executed in server and JS is automatically generated, meanwhile GWT is executed in client, server data must transported to client.
I want to start building hybrid HTML5 mobile apps; build the core functionalities via HTML5, then wrap this with a native layer for iOs, Android, BB..etc
After some research: I found I need to be familiar with plenty of technologies, namely: HTML5, JS, CSS3. Other technologies/frameworks I was advised to be familiar with: JQuery for Mobile, Sencha touch, Node.JS, Backbone.JS, PhoneGap..etc
Till now I just know the basics of HTML5, JS & CSS.
My question is:
Is there a "single" place (Book/Tutorial/Screen casts) where I can find a walkthrough Tutorial that deals with some of these technologies and guide me to building hybrid HTML5 apps (Maybe on iOs for example)..
I would want to learn the mentioned technologies among these, yet I am pretty keen on learning them in the context of building a hybrid mobile app and not on separate basis. I much prefer learning by doing real work (The app in the Tutorial/Book/Screen cast here) rather than learning each technology on its own.
Much appreciate your answers.
Omar
OK, let me expand my original answer:
HTML is short for hypertext markup language.
It is used to specify how to display STATIC content via the HTTP protocol, vulgo web.
HTML5 is version 5 of the HTML language specification, and is a RECOMMENDATION to a standard, but not really a standard by itsself.
CSS is used to apply advanced STATIC formatting to STATIC text/images, such as alternating background colors for even/odd rows in a table, text-flow, text-direction, size, boldness, font etc..
To make static content DYNAMIC, you need JavaScript.
JavaScript is a scripting language, that runs in the webbrowser of a vistor (client) to the website. Theoretically, it is meant to behave the same on each browser, but in reality, Microsoft used unfair competition and intentionally crippled the JavaScript implementation in it's browser (Internet Explorer), by diverging from the ECMA standard, and by implementing proprietary features, to stifle competition (Netscape) and make it impossible to develop compelling web applications, for example online office software.
JavaScript, the client-side programming language, is complemented by PHP/ASP.NET/JSP, which are programming languages & frameworks that run on the server, and are there to dynamically create static pages, for example by filling in data from a database, and to process and save user input, such as orders, payment, emails, feedback, etc, and to process input from HTML forms (input masks).
JQuery is a JavaScript framework.
That mainly means, it's a library of JavaScript functions that were designed to provide often-needed functions that do the same on each browser, effectively bypassing the anticompetitive practises of software vendors such as Microsoft and Apple.
It also provides basic functionality for event handling, graphics and AJAX (asynchronous JavaScript and XML), and functions for serializing/deserializing JSON (JavaScript object notation).
JQuery for Mobile is a version of JQuery optimized for mobile devices, such as Android or the iAnything. So are Sencha touch, Node.JS, Backbone.JS, etc.
The difference between HTML 5 / and HTML4/XHTML is mainly that HTML5 provides a so-called "unified" way to embed audio video. Which is not necessarely true, because each browser supports different audio and video formats, and there is NOT ONE audio & video format that is universally supported across all browsers.
HTML 5 also provides the very useful WebSockets, which basically allow you to make client-server applications on the web. Since this would enable compelling web applications and office applications that would be on par with Microsoft Office, Microsoft hasn't implemented WebSockets in the standard browser. It's available as separate plugin, which basically nobody bothers to download, which means one cannot use web sockets anytime soon if the web application should work with internet explorer. Additionally, HTML5 is only implemented by IE9+, and not by IE8. IE9 however is only available for operating systems newer than windows XP (vista, 7, 8). Which means one cannot install IE9 on Windows XP (35 percent of current windows installations, Windows makes up 85 percent of the desktop market).
To embed web applications on mobile phones, you need to embed your applications in a embedded WebBrowser. For Android, the interface to the embedded browser is called WebView, and you need to learn the Java programming language to use it. For Apple, I have no idea whether they have such a thing at all, but I'd suppose they have, though it's probably going to be more complicated, since that's Objective C, and not Java. Since I have neither a iPhone nor an Apple computer, I cannot tell you anything about it, except that it's crap because it doesn't support Flash, and that it costs 10 times more than what it's worth..
Screencasts, you'll probably find on youtube, if there are any.
Again, google search will provide you with the necessary answers if you have a specific question.
My question is: Is there a "single" place (Book/Tutorial/Screen casts)
where I can find a walkthrough Tutorial that deals with some of these
technologies and guide me to building hybrid HTML5 apps (Maybe on iOs
for example)..
Yes, http://www.google.com/ncr
You know, it has a wonderful search box for just about any problem...
Other good pages:
http://www.w3schools.com/html5/default.asp
http://www.w3schools.com/js/
http://docs.jquery.com/Tutorials
Here is an update on this question, as building hybrid apps have come a long way in three years.
I would start with looking into Phonegap, or the Adobe owned version called Cordova. This is a very popular route in quickly developing and distributing hybrid cross platform mobile apps. So popular in fact many other frameworks are built around the Cordova framework to give it a more native feel, such as
Ionic - this is by far the most popular, it's open source (free) and my favorite as I find the quickest and easiest to work with. In addition they have great documentation and great pre-builds. It's command line interface framework that works combines the Cordova, Bower (a package/plugin manager), Grunt and Angular JS frameworks into one powerful and quick CLI. If you are unaware of these frameworks they're definitely worth looking up if you're looking into building web or hybrid apps.
Mobile Angular UI - is an HTML 5 framework which uses bootstrap 3 and AngularJS to create interactive mobile apps.
Titanium - is a "complete" solution for creating hybrid mobile apps with all you need in one place with there downloadable program Titanium studio
Telerik - a website based program similar to Ionic and titanium for rapid development
Those are great places to start. If you don't already have a subscription to Lynda.com I would highly suggested it. The subscription is roughly $25 a month depending on your location. They have hundreds online video courses that can run a few hours long and are very great I giving you a good scope and how-to do many projects and understanding many frameworks. teamtreehouse.com is another great tutorial tool they have a lot smaller selection of videos better more in depth and hands-on and will work with many other frameworks with in the project.
You want to learn how to develop a hybrid app that works with multiple platforms such as android, iOS, Windows, etc. This means you need to learn PhoneGap and Cordova(preferred). These are almost the same, one really is part of the other.
Google both phonegap and cordova, install the packages (requires a little bash command line knowledge). It is relatively quick and easy to get the example HelloWorld app in both Phonegap and Cordova.
After that? well, you will have to learn HTML, CSS, javascript at minimum for the web side of a hybrid application. The native side (Android, iOS, etc.) will require learning Android Studio/java for android, or Xcode/swift for iOS.
Everything you want to learn is either on youtube.com for free, or Udemy, Udacity, Lynda. Some sites you will have to pay for, but its WORTH IT.
I have been assigned to build a mobile web application. I have found two ways to develop that (there might be hundred other ways to do that, but I am aware of these two): jQuery Mobile and HTML 5.
Which one should I use? The application will be a normal web app, like a shopping web app or a user management system.
I am looking for compatibility in different phones and great UI with fast processing.
So, the ways I know is JQuery mobile and HTML 5.
Which one should I use?
It's not a case of using one or the other - you use both to create a solution.
HTML5 provides the framework to present your content, whether it is text, images, video, audio, or any mixture of the above.
jQuery (Original or Mobile) is used for "Progressive Enhancement", that is to provide additional functionality, features or flair to the HTML5 framework.
To ensure the best compatibility across the majority of devices, you want to have a website which is usable without the jQuery enhancement. Then, once you have that, you can use jQuery (and/or standard javascript) to add the "nice-to-have"s, like animations, AJAX interactions, geolocation, etc.
Lucanos is right in the sense that HTML and jQuery aren’t alternatives. (Browsers display HTML, and then you write JavaScript — possibly using a framework like jQuery — to manipulate that HTML in custom ways where necessary.)
However, if you‘re using “HTML5” in the Apple sense of the word (i.e. to describe HTML5, CSS3, and browser-specific extensions to CSS), then there are some choices to make — e.g. some WebKit-based mobile browsers support CSS animations, which should perform faster than JavaScript animations.
I’m not familiar with jQuery Mobile — it might well use CSS animations when they’re supported, and simulate them when they’re not, meaning you get wider compatibility without much runtime performance cost.
But for mobile, personally I think you’re better off picking the most popular platforms (i.e. iOS and Android), and writing to their capabilities, without bothering with a framework like jQuery Mobile. That way you serve most of the market with less effort (and thus serve them better), rather than making everyone download jQuery Mobile just to serve a few older phones that’ll get binned in a year or two anyway.
Disclaimer: this depends entirely on your target market. If they all use old phones, write to the capabilities of those phones.
Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.