[thomasfl]

Mobile app is most most certainly going to be made using html and javascript in the time to come. Ionic and angular is great for building mobile apps with standard mobile UI elements like headers with back buttons and chevrons, pages that slides in from the side, modals and tab bars at the bottom of the screen. Everything is meticulously created in html, css and javascript. Scrolling is good enough for most usecases, but if your pages contains long list views with graphic elements the page starts to lag.

However if you use famo.us' list view scrolling is nearly as fast and smooth as native code on iPhone 4. On newer phones to difference between hybrid apps and native is unnoticeable. At the moment famo.us only has low level components, like boxes with html content. Standard back buttons, chevrons, tabs, action sheets and icons has to be imported from elsewhere. Famo.us only does fast bouncy animations, touch events and 3d effects. Besides famo.us is working on their phonegap/cordova alternative wrapper.

A combination of Ionics ease of use and famo.us' impressive speed would have been great. There's lot of promising little open source projects on github that either extends famo.us or integrates it with javascript MVC libraries.

I believe Brendan Eich was right when he said "Always bet on JS!". I bet mobile app development is going to be dominated by JavaScript and HTML.

[no_future]

What a dreadful notion, I hope this never happens. Development on mobile devices is a great way to develop on a web connected platform that reaches lots of consumers, but instead of using horrible, ancient tools that are expected to do things today that they were never designed to do at the time of their inception(HTML/CSS/Javascript), you can use capable systems languages like C(and now Swift, which I have no experience with but have heard generally good things about) and Java.

That I call traditional frontend web tech ancient and out of place today isn't even really an opinion - the deluge of Javascript/CSS frameworks, compile-to languages,and lists of best practices would suggest that something is wrong there. Web stuff is just way easier to get into so there are a huge amount of developers available, especially the types who spend more time yapping on their blogs about the latest overhyped software trend than actually writing software.

I don't know about animations and whatnot, but for games and image processing i.e. 2 enormous chunks of all mobile software, Javascript isn't replacing anything anytime soon.

I don't understand why someone would want to spend hours trying to optimize languages which weren't designed to run native software on a platform to be as effective as the ones that were when you could just write the software in the native language, to me this just seems like an exercise in futility. Even moreso considering the fact that Javascript and HTML are horribly unproductive languages, though I suppose since so many people know them well they can be more productive in them than in a language they don't know.

[matthewmacleod]

I don't understand why someone would want to spend hours trying to optimize languages which weren't designed to run native software on a platform to be as effective as the ones that were when you could just write the software in the native language, to me this just seems like an exercise in futility. Even moreso considering the fact that Javascript and HTML are horribly unproductive languages, though I suppose since so many people know them well they can be more productive in them than in a language they don't know.

I don't understand how you can fail to understand this.

People want to write cross-platform apps for mobile devices. The marketplace is pretty evenly split between iOS and Android devices, and anybody releasing an app probably wants to make it available on both platforms. However, the cost of using two entirely separate tooling stacks to do this could easily be far too high for small apps.

Your dislike of HTML/CSS/Javascript is pretty baseless too. Lots of developers like them, are productive in them, and don't feel that they're all that bad. The fact that compile-to-JS/CSS languages exist is meaningless – it's like complaining that assembly is useless because nobody uses it directly.

And bear in mind that JS now approaches ~0.5x native C code performance with Asm.js – this is better than Dalvik[1]. That opens up a lot of options.

[1] https://blog.mozilla.org/javascript/2013/08/01/staring-at-th...

[no_future]

>it's like complaining that assembly is useless because nobody uses it directly

Everybody always tries to make this comparison(WELL IF YOU WANT IT TO RUN SO GOOD JUST WRITE IT IN ASSEMBLY), and it really goes to show how little they know. Programmers don't write things in assembly because today's compilers can write much better assembly than pretty much anyone. No compiler can write C better than even a mediocre programmer, which is why if you want to write something that runs very smoothly or requires high performance stuff, you write it in a C-family or JVM language. That aside, specifically your comparison makes no sense to me. Everything is assembly underneath, so I don't think anyone would say that it is useless unless they had part of their brain stem missing. HTML and JS have no place on mobile(aside from fools trying to shove them on there, hence my rant), they could be completely removed from the equation and nothing would change, and people who actually want to build good products rather than SHIP AS FAST AS POSSIBLE AT THE LOWEST COST POSSIBLE ON EVERY PLATFORM SIMULTANEOUSLY SO WE CAN MAKE THE MOST PROFIT POSSIBLE FUCK IF IT RUNS LIKE SHIT could chug along making great products, with languages designed to make great products on that platform. The developers that feel they "aren't that bad" are probably ones who haven't used anything else and don't even care to try, which is why they are trying to make them work on mobile.

[akmiller]

> Programmers don't write things in assembly because today's compilers can write much better assembly than pretty much anyone.

I don't buy that statement. In college we'd write a small program in assembler, then write that same program in C and compare the generated assembler code. The generated code was always longer than the hand-written code and often times significantly longer.

The main reason we don't write assembler anymore is we don't need to!

[matthewmacleod]

it really goes to show how little they know

I don't know – as a developer with many years of experience, from assembly to web technologies, I think I'm pretty qualified to make this comparison :)

No compiler can write C better than even a mediocre programmer

That's not true at all – there are a whole bunch of examples which transpile other languages to C. The point is to work in a system that effectively communicate's ones intentions – that fact that it's C underneath is almost irrelevant.

Everything is assembly underneath, so I don't think anyone would say that it is useless unless they had part of their brain stem missing

I'd argue the same for the combo of Javascript, HTML and CSS, given that it's one of the few cross-platform tool for building user interfaces. Anybody arguing that it's useless is missing the big picture.

HTML and JS have no place on mobile(aside from fools trying to shove them on there, hence my rant), they could be completely removed from the equation and nothing would change

I mean, they clearly do. Otherwise, we wouldn't have a web, and every site that currently exists would be accessed through a native app. That's obviously silly.

and people who actually want to build good products rather than SHIP AS FAST AS POSSIBLE AT THE LOWEST COST POSSIBLE ON EVERY PLATFORM SIMULTANEOUSLY SO WE CAN MAKE THE MOST PROFIT POSSIBLE FUCK IF IT RUNS LIKE SHIT could chug along making great products

No, there's a distinct tradeoff to be made. Let's say you're a service with a small staff trying to publish a mobile app. You obviously need it to work across multiple platforms, given the current state of the market. In many cases, the cost of maintaining two separate codebases, and two separate teams, will simply not be worth the expense. If you are delivering a relatively simple app, then it's something that could quite possibly be built using the web stack – sacrificing some quality of UX in exchange for actually having a shipping product at all.

The UX of a native app will continue to be better for the moment. But the gap has closed significantly in the past couple of years, and I don't see any reason that it won't continue to do so, as platform developers and others work to fix the remaining issues.

The developers that feel they "aren't that bad" are probably ones who haven't used anything else and don't even care to try, which is why they are trying to make them work on mobile.

I've personally developed native applications for Android, iOS and Blackberry, and have also developed a couple of cross-platform apps that ran across all three with Phonegap. The UX wasn't as good as fully-native apps would have been, but building multiple apps would not have been cost-effective in these cases, and the output wasn't all that bad. So I guess that invalidates your point.

[no_future]

Sure there are languages that transpile to C, but they don't run as well as hand written C. I wasn't saying that compilers couldn't write C, I was saying they couldn't do it better than a human.

[scriptproof]

"instead of using horrible, ancient tools" (JavaScript=1995, HTML 5 spec=2014) "use capable systems languages like C" (Objective-C=1982, C=1972, Java=1994). WTF?

[no_future]

C-family languages are still the best languages for systems dev, they've aged well, and Java is good for it as well. Systems dev hasn't changed much since they were developed, mostly just more transistors and cores were shoved into processors and more RAM became available. And it still stands that pretty much you can do with a computer, you can do with C. This is NOT the case with JS/HTML. HTML was developed during the time of static webpages, and JS was literally cobbled together in 10 days, and meant to provide functionality where webpages could talk to a webserver off in the background and not have to refresh, and to make HTML more dynamic.

The rich web applications that have become standard today are not what HTML and JS were designed for, hence, as I said before, the deluge of frameworks and compile-to languages that try to put bandaids over Javascripts warts. Even huge players like Google push stuff like Dart because JS is so bad.

Few people have tried to develop a replacement for C(aside from fringe projects like Rust), mainly because it's good at what it does - anything you can do with a computer. Yes, Swift is meant as an ObjC replacement, but it seems more aimed at improving programmer productivity than fixing anything wrong with ObjC.

HTML AND JS WERE NOT DEVELOPED TO RUN NATIVELY ON DEVICES! WHY WOULD YOU WANT THEM TO RUN ON DEVICES?

[grey-area]

HTML AND JS WERE NOT DEVELOPED TO RUN NATIVELY ON DEVICES! WHY WOULD YOU WANT THEM TO RUN ON DEVICES?

Please don't shout. HTML and JS were developed to run on any device, past, present and future. HTML is actually pretty good at presenting most UI state along with documents - the UI of the vast majority of native device apps is really not hard to present as html, the only roadblock is the vendors lack of focus on mobile web view performance. JS is a mixed bag, and as you say pretty rushed, and not the favourite language of many - I wouldn't want to write an app in it, though of course it is possible.

The choice developers are presented with here is to commit to learning each new API/Language on the continually shifting sands of OS vendor APIs for multiple vendors/devices, or to commit to an open but less performant toolkit they know will be around for a while, but which has the advantage of being stable, cross platform, and not tied to any specific vendor.

Clearly you don't feel the pressure of being tied to specific vendors and having to produce multiple binaries on a growing array of platforms both mobile and desktop, but others do, and this is mostly why they choose to use web tech on mobile or desktop. It's a very political and economic choice not one based on language syntax or capabilities alone, if you attempt to simply compare C and js on a technical level for example you will fail to understand why the choice is made. I fully expect that trend of web everywhere to increase if/when HTML starts offering more choice of languages (NaCl/asm.js) and perhaps more sophisticated layout (though for present uses it's not bad for that purpose). At that point, why choose a native API which will be deprecated in 5 years, when you can truly write once and run anywhere (web, mobile, desktop).

The people native apps benefit the most is OS vendors, because of lock-in, for both consumers and developers having a more open cross platform tech is clearly desirable (easy to switch platforms or for developers serve all platforms), even if not fully practical at present.

[no_future]

>The people native apps benefit the most is OS vendors, because of lock-in

C and Java can run on any platform(far more than HTML and JS which were developed to run in browsers), what lock in?

[grey-area]

The APIs provide the lock-in. With the exception of posix, they're platform dependent.

[findjashua]

This comment would be spot on 2 years ago, but once you try libraries like Ractive or React, it's iOS/Android that begin to feel ancient. How do they not have data binding in 2014?

Also, having to maintain a separate codebase for each platform just seems inefficient. The solution doesn't have to be Javascript (could be C#), though Ractive and React make it surprisingly pleasant to write JS.

[andwaal]

You know that one of the main things that React(w/flux) tries to fix is all the errors made because of data binding..

[findjashua]

I use that term loosely to mean that my even-handlers only have to update the component's data, and the library takes care of updating the view.

That said, I've used Ractive for a while (on my own time), and haven't run into any issues. But I'm curious to know more and would like to try it out. Could you give me an example where data binding would cause errors?

[pjmlp]

Only if you never tried XAML Data Bindings.

[findjashua]

I'm assuming you're talking about Xamarin? If so, $1000/yr is pretty expensive for small teams.

[thewizardofmys]

I don't see what the problem is if people try to make things easier. As you said web stuff is easier to get into and development there is easier and this is a very good reason why apps should be easy to develop too. App should be as easy to develop as web apps and this is not a bad thing, people's time, energy, intellectual capacity will be saved.

[al2o3cr]

"Scrolling is good enough for most usecases"

Is this really where we're happy being as an industry? "Don't worry, since you've got the most powerful pocket computer ever shipped the scrolling is usually only mildly terrible."

[pjmlp]

> I bet mobile app development is going to be dominated by JavaScript and HTML.

If that is all one knows, sure.

Luckily there are other alternatives, Xamarin, Qt, SDL, Cocos2D, Unreal, Unity...

[cfontes]

Very nice comment.

Thank you !