If you had to start over, what technologies would you learn in 2014?

He mentions Java, twice. There is nothing wrong with making web-apps in Java, and there are some nice web frameworks to help doing that.

I think the main question is if mobile web applications will be able to match native on both quality and performance.

Facebook attempted this and failed badly, but that doesn't mean it can't happen or that native will always have an edge. If native does continue to have an edge though then I think web has an uphill battle.

  > hide the difference between apps and web apps

Web applications had this problem circa 1998 - i.e. a perception of slowness - look at SalesForce now!

"Whoever can make the Google of app discovery might make a temporary splash, but i bet that, not long after, people will return to plain old Google Search."

You remember me to Kodak's "people will return to make analog photos, people want to hold something in their hand".

You are deluding yourself, and you can't see what you have in front of your eyes.

No, there is not a single platform that works in everything. In my company we do both low level programming(c, c++[small controlled subset so we control it]. embedded, microcontrollers, hardware) , and high level programming (python, java, web programing in general) for scripts, testing , rapid prototyping or deployment...

Both of them work very well for what they are designed for.

If we paint something in the screen in c we could do it in 0.001 seconds(without hardware accel!!), in python it is 0.5 seconds, 500 slower!!. In the browser is like 500 if we were to do things on javascript. Most people fake and call webgl with hard pre calculations done in a server(native) "web programming". It is not.

And we use python a lot. Because we don't care if something takes 5 seconds to draw if this saves hours or days of debugging.

In the future communications will be better, and program interaction will be stronger, but that does not mean that all software will be web. Multiplattform native works also very well, and much better for some things.

"Given that the world's #1 mobile OS is made by the worlds #1 web company, this change is not difficult to predict."

Android is not web for a reason. It sucks for lots of things. It is not that Google has not tried, as it is in their best interest to do so.

The interest of a web company are something, and the interest of consumers are something else.

Consumers probably don't like having to be connected all day, all what they do in their computers being monitored in real time and stored forever by the NSA.

You probably are American but there is people living in other countries, with different interests. As Snowden said the NSA uses their tools for industrial espionage(as should be expected).

If you have a company outside the USA you will have no brain if you used web for your secret sauce. They will take it from you, they will give it to an American company and even patent it. With native it is orders of magnitude harder to do this.

For anybody doubting this, please read Clay Shirky's "Permanet, Nearlynet, and Wireless Data". [1]

[1] http://shirky.com/writings/permanet.html

It's a fun read in a post-iphone world but the money quote is:

The permanet strategy is to start with a service that is good but expensive, and to make it cheaper. The nearlynet strategy is to start with a service that is lousy but cheap, and to make it better. The permanet strategy assumes that quality is the key driver of a new service, and permanet has the advantage of being good at every iteration. Nearlynet assumes that cheapness is the essential characteristic, and that users will forgo quality for a sufficient break in price.

What the permanet people have going for them is that good vs. lousy is not a hard choice to make, and if things stayed that way, permanet would win every time. What they have going against them, however, is incentive. The operator of a cheap but lousy service has more incentive to improve quality than the operator of a good but expensive service does to cut prices. And incremental improvements to quality can produce disproportionate returns on investment when a cheap but lousy service becomes cheap but adequate. The good enough is the enemy of the good, giving an edge over time to systems that produce partial results when partially implemented.

The people on the web platform have much greater motivation to improve perf and the developer experience than the people working on native platforms have to expand distribution.

Completely wrong, imho. There's no benefit to obscuring information about what the user is doing. This also implies a universal cloud storage where authors of software have more access to user's personal information than the user.

You're basically yearning for what Google's Chrome crap is trying to do, so you're not going to do it better.

> Given that the world's #1 mobile OS is made by the worlds #1 web company, this change is not difficult to predict.

I think I see where you're coming from here. If you just want to suckle at the tit at what ever company is #1, then sure, learning their stack and developing whatever for it is a sure way to make steady income. Shit, how about a steady job while you're at it. Then it really doesn't matter what widgets you're pumping out. Wait, is this an entrepreneurship forum? Anyway, trying to play Google's game or Apple's game is just a good way to be their bitch. I'm sure you're aware of why "discoverablity" has been removed from appstores. This is a culture war, at some fronts.

If you want to build a digital prison for your mom, go right ahead, but don't expect your kids to embrace this "cloud" stuff in any way that you're dreaming of. You're just building outdated virtual landfill techgarbage the moment you touch any of these paradigms you're talking about.

I agree, but not for the technical reasons most people are mentioning so far.

I think there is a much simpler driving force: mobile app stores have set both the quality bar and pricing expectations so low that it's almost impossible to develop good, non-trivial software for them and make money.

On top of that, the app store platforms tend to want a big cut and/or restrict the use of other payment models and/or want developers to jump through hoops just so users can install their application and/or require developers to build in a specific programming language that produces executables for their specific platform and/or a bunch of other obstacles that web development simply doesn't have.

Meanwhile, the only major benefit native apps have to offer in return these days is access to a few native features. Given how much success many web applications have already enjoyed, it's clear that those features aren't compelling in many of the application domains where this kind of decision is being made. It's also clear that if performance was ever really an issue for most web apps, it's an ever diminishing one and mostly irrelevant by now.

The two major business models that have made serious money from mobile apps other than in outlier cases are in-app payments and advertising, which are probably the two most widely abused and consumer-hostile payment models in widespread use today. I suspect mobile apps in their current form were already dead as a serious software platform as soon as people were selling $1 gimmick applications and $5 puzzle games in app stores. The industry just hasn't quite realised yet because there's still too much hype from the (mostly now over) gold rush, but fortunately we have high quality and great value apps like Dungeon Keeper at the top of the promotions screens to show us just how good mobile apps can be if you want to make real money from them.

Meanwhile, as numerous HN regulars can attest, plenty of B2B web apps are making money like it grows on trees, and plenty more people are making a decent amount of money with other B2C business models that simply aren't compatible with today's mobile app world but work fine on the web.

I'd only amend this to say "web startup." While HN is very web-centric there are a lot of other startups out there that have nothing to do with the web.

That said, I'm not sure where the bar is, even in web. Writing Chrome extensions and apps? Javascript injection on mobile? Dart? Web Components? Ember? (ouch) Angular, or React.js? Or a certain company's stack like Closure? And don't forget security vulnerabilities and keeping up with OWASP checklists or UX improvements, prototyping in HTML. And then there's performance considerations, eg. what Ilya Grigorik writes about these days. And touch screens, mobile, responsive... Front-end has a lot of transferrable skills, but it's a complex beast too, often full of legacy code.

which is why the talent pool is larger and salaries lower.

No it's not. Because JavaScript the language is so bare-bones, you need to supplement language deficiencies with frameworks and libraries. So you go and pick from a menu of Backbone/Marionette, Angular, ExtJS, Ember, Kendo, jQuery or etc. - some of them work together, some of them don't. Most of those get you part of the way there, you may still need to pull in things like require.js to manage imports. Or, instead of raw JS, you go with TypedScript, or Dart, or CoffeeScript, or whatever, and then put a framework on top of those. You're still not done, because that gets you the JS part, usually you complement it with a CSS framework (like bootstrap) and a SASS framework. In the end, you have a hodgepodge of frameworks of libraries, that plug JS holes, and functionally look and feel different.

So no, it's not simply JavaScript everywhere.

Obviously, if the project is far outside the sweet spot of a given programmer's favorite language, it's worth it to learn a different one. The larger the project, the more often this is true. If for example, a Java specialist wanted to build a webapp, it would likely be worth it to invest the effort to learn how to do so with JavaScript instead of sticking to the familiar GWT. But for a smallish text manipulation task, it's just not worth it for an expert user of Ruby (a pretty good text manipulation language) to learn Perl (a language really designed for text manipulation).

The sweet spot, in my opinion is to work at getting very good at one language per major domain area and change focus only for large projects, for projects far from the sweet spot of any already known languages or for fun.

Interestingly, literature has the same problem.

That way, you aren't spread thin as you learn everything for the first time, and when you learn new languages you can relate them back to your first language, of which you have a complete grasp.

Naturally in the long run you want to be totally language agnostic, but early on I think that's putting the cart before the horse a bit.

Also, you have guys like me, who code as an ancillary function to our actual job. For us, one or two workhorse languages are all we really need to invest our time in. Think of a physicist who knows Fortran, for example. He is a "Fortran guy", but that's ok. He's a physicist, not a developer.

"Right tool for the job" is getting to be a very tiring orthodoxy. It seems to come around whenever people don't want to get into the nitty-gritty of comparing tools. I say stop the handwringing, pick something that feels right to you, and start doing stuff.

Outside probably Java and C#.

Its about being a professional in the way you handle the tools at your disposal.

This has been going on for a while. It was noted last century that a job opening asking for "5+ years experience" in a technology that was 3 years old.

i) Wrapper libraries - Sure you can download them from definitelytyped but in practice I quickly found all sort of incompatibilities and things not working when used on real versions of the wrapped libraries. I had to edit them based on suggestions from forums. They are unversioned community efforts - poor versioning and no package manager is just a nightmare given the dozens of libraries we have to use for modern JS.

ii) Tooling - I thought this was the benefit and tried using it from WebStorm which claimed Typescript support. I found no meaningful intellisense only that it shelled out to the TS compiler in the background with some flakey syntax highlighting. The worst issue was that the compiler could regularly produce totally opaque error messages that were poorly located to the code issue and probably in the wrapper somewhere.

iii) Arbitrary apis - this is what I thought I wouldn't face but it was. Just a single line of code trying to the most basic task of creating an express server took hours of googling for the magic incantation. Most advice referred to the wrong version. It appears there are javascript patterns that typescript wrappers struggle to represent so the authors have to invent new ways of offering an interface. Wrappers don't come with documentation... even if they did, you now have to read both the original and the wrapper documentation. Not cool.

I hope some of this is now fixed but to have unreliable wrappers, no versioning and bad error messages means I am not hurrying back anytime soon.

Another aspect is that mobile / tablette apps are moving from a "mostly read" to a "read/edit" usage, thanks to the exponential power gains inmobile CPU. That means what the web will have to compete against on mobile isn't facebook stream but rather full blown photoshop.

People at Netscape were talking about the web displacing native applications twenty years ago. That hasn't happened yet!

I'm in favor of application logic living on the web, with native apps used on the frontend for consumption.

EDIT- If anyone is interested in this area, let me know!

Ripe for disruption. Billions over billions.

Source: This is what I do.

Typescript doesnt fix javascript issues, it just extends it. It means you'll get some nasty bugs in your code if you think you can just ignore javascript.

I really don't know why people have such a problem getting to grips with pure-C++ functionality like templates, virtual functions, inheritance, RAII, exceptions, references, type system oddities, rvalues and lvalues and their references, operator overloads, extended temporary lifetimes, smart pointers, runtime type information, the lack of decent unicode support, slow compilation times, binary compatibility which is tricky to maintain, member function pointers, virtual base class construction order, SFINAE, and static polymorphism and concept checking.

It's really not that difficult... ;)