Folks, the big point of this article is not that Hanselman likes C#, it's that his list of options does not include Objective-C or Java. It's that he thinks that the web will win (over app stores). I strongly believe that he's right there.
At some point, app stores had "discoverability" as an advantage over the web. This has been one of the strongholds of native app proponents. These days however, with the enormous amount of apps available on popular platforms, this discoverability feature has become a joke. It's akin to searching the 1999 web for interesting sites but you can only use a badly managed, bribe driven version of Yahoo.
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 only need 1 major mobile OS to change paradigm and hide the difference between apps and web apps, and your mom won't care anymore. Given that the world's #1 mobile OS is made by the worlds #1 web company, this change is not difficult to predict.
I was under the impression that you could build pretty decent robust apps with Rails / Django. OK, you wouldn't want to run the size of Amazon on those, but the majority websites are orders of magnitude smaller.
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.
On Facebook, I remember a time when the native app was horrible on Android.
In many ways it still is - it requires too many permissions and the list is growing. Recently they're asking for access to my SMS messages and in Android 4.3 I had a bug with my Nexus 4 in regards to location services as the Wifi-network provider was draining my battery and so I had to disable it, so Facebook's app was still requiring it, activating the GPS on each opening of the app and there was no way to turn that off, unless I turned the GPS off globally. Granted this is also a failure of Android's permissions system, but ...
The mobile web interface was and is still there. It doesn't matter if the mobile platform is new or old, it doesn't matter if Facebook's app was developed (and approved) for that platform, the web interface is there and it works, the only requirement being for the user to have a decent JS-enabled browser.
People view Facebook's investment in their mobile web interface as a failure. I view it as competitive advantage.
I suppose in your case you're choosing between two bad options.
The iOS app is an example of how much better a native app can be from the web app - and the new paper app even more so.
I remember the android one being terrible when I had android phones a couple years ago - but I thought that was because it was basically a wrapper around a web app.
What if history repeats itself? What if iOS will in the end fail in the marketplace, reducing its share to a single digit? What if Apple continues against all odds to develop and support it, like it did with the Mac OS? What if you'll still use it?
Wouldn't you be happy then that there's a web interface available?
And from a developer's perspective - you could say that you want to target iOS users first. That may work out well for you. However, for example, I never, ever tried Instagram because when Instagram was all the rage, it wasn't available for the platform(s) that I'm using. And later the momentum for me was gone. That's a lost opportunity.
In the end, it may work out well for the developer - however, considering that iOS's marketshare is minuscule compared to the people that have access to web browsers, I personally don't see how you can build the next Google or Twitter or Facebook by not targeting the web first.
For another example of companies that failed to do this - WhatsApp Messenger will probably die or get acquired, because Facebook is eating its launch, as Facebook works everywhere and when I send a message to my wife, she either reads it on her phone, or in the browser tab that she keeps open when on her laptop. FB's messaging works on my iPad too, whereas WhatsApp doesn't because WhatsApp is identifying users by their phone number.
That is a good point and I don't disagree with it.
I suppose mine was more targeting the difference between mobile native applications and mobile web wrappers.
Facebook's web interface for 'real' computers is great and companies that don't have one would probably benefit from one for the reasons you mentioned.
On the mobile side though I still think native applications are worth the investment and that'll be hard to change unless the web apps can actually offer similar design and performance.
Facebook, Twitter, and Google are fair examples, but in each case, what makes these things hard is the server components.
Now consider what it would take to build the next Final Cut Pro. You could try to do it as a web app, and you might even get some casual users who don't need much capabilities. But you are not going to displace existing professional tools on any platform.
Being available everywhere just means you're not better anywhere. Java apps discovered this last decade.
The iOS app is an example of how much better a native app can be from the web app
Huh? My perception of the Facebook iOS (iPad) app is that it is badly, badly broken.
It opens links within the app and there is no way to override this behavior.
This means I can't browse Facebook-sourced sites alongside everything else I'm browsing or bookmark those sites in Pinboard. I can't even copy & paste the URL from the Facebook app into mobile Safari.
I uninstalled the Facebook app within minutes of downloading it. The web interface just works better.
You can remove the word mobile. Web apps are still heavily inferior to native desktop apps. The answer to 'why mobile web apps?' is the same answer as to 'why desktop web apps?'
Depends on your definition of inferior. I can count the number of desktop apps that I use on a daily basis on one hand, and they're all development tools. I have more than twice that number of pinned tabs in my browser that are open at all times.
Are those pinned tabs all running applications or merely displaying information (websites)? Are you sure the ones running apps would not run better were they written as a native/desktop version? Are the apps trivial (e.g. to-do lists)? There's a lot of context you left out.
Some are just websites, but I would say many of them are full blown apps:
Gmail - email client
Mog - Music player
Google Voice / MightyText - Messaging
TweetDeck - Twitter client
Confluence - Team wiki
Trello - Organizational tool
Toggl - Time tracking
Bitbucket/Github (I suppose you could debate that these are
just websites)
Google Drive - Document editing and storage
Would these run better as native apps? Probably, if you're just talking about raw performance. However, I frequently jump between OSX, Windows, and Linux machines. When I open Chrome on any of these devices I can pick up right where I left off. Could I say the same with a native app? Probably not. For me, the performance of the web version of these apps is good enough, so cross platform compatibility becomes more important than raw power. That's what I meant when I said it depends on your definition of inferior.
I don't think mobile hardware or mobile browsers are quite there yet. But I don't see any reason why they won't eventually get to a point where they're "good enough" for people like myself, at which point other factors beyond raw performance will become more important.
I generally agree to this, but at least with mobile you carry your phone with you all the time. I could see the benefit of a web interface on any machine you use rather than having to have your laptop with you for the desktop app.
Though I guess I usually have my laptop with me anyway.
Facebook was just a bit too early when trying to make html5 work on smart phones. If they were to make the attempt again today it would probably successful.
React [1] batches writes to the DOM automagically, which was the main problem with the original app that prompted the FB post. Sencha did a version that worked fine with then-current hardware/browsers.
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.
Frankly, this is only possible by web apps not being web apps.
Do you have any experience working with eiterh native SDK?
Because I cannot imagine any one having experience (not just cursory hello-world glance) thinking that web apps are somehow superrior.
I also don't get how web apps are better (or will be better) discoveralbility-wise. Or why it matters.
Frankly, this is only possible by web apps not being web apps.
I'm not sure I agree with that, though it might never happen because the owners of the major platforms have absolutely no interest in being turned into a dumb foundation by the web (or a badly debugged set of device drivers, as Andreesen put it in 1995). The reasons for the ascendance of mobile are political and corporate though, not technical. There's little reason webkit performance cannot approach that of native, particularly if it used something like nacl rather than js, and no reason APIs cannot be exposed to web apps too (Apple exposes quite a few).
Web apps are currently superior in: deployment,future-proofing, IMO discoverability, platform independence, and most importantly cost
Native apps are currently superior in: performance, accessible APIs, 3D
Their relative strengths will change over time, but note that performance is not usually an insurmountable obstacle, while some of those areas where the web has strengths are inimical to the way Google, Apple, MS or Amazon want to do business - for corporations to tie in their customer as tightly as possible to their ecosystem and tightly control what is available to them (as Apple have for example banned kindle selling on their platform) is the best possible outcome. App stores are broken by design, just as the MS desktop monopoly was, and I don't think they will be able to surmount those problems, because they are fundamentally user-hostile. Why can't I buy kindle books on my ipad? Because Apple wants to make money from that transaction.
The web has other problems, among them a worse is better approach in many areas, but I think it's ultimately going to prevail over other solutions bound to a specific hardware/software stack.
> There's little reason webkit performance cannot approach that of native, particularly if it used something like nacl rather than js, and no reason APIs cannot be exposed to web apps too (Apple exposes quite a few).
While I agree with that sentiment, I disagree with the example provided ... if you talk about NaCL, you're not talking about web apps or "the web" anymore. It's not a standard, it has portability issues and it will probably never be implemented by anybody else other than Google. We can bitch and moan about how broken the W3C standardization process is, but the existence of this process is also why the web is open and why it's awesome.
The alternative asm.js, while not being an answer to all issues addressed by NaCL, is a much better approach, because it's still standard JS and even if the browser does not optimize for the asm.js instructions set, the app still works - and if it takes off for games (and I believe it will), then all browser vendors will be forced to optimize for it - because it's one thing to not support some plugin (e.g. NaCL) and quite another to have clear instances in which the browser is much slower than the competition and thus directly comparable.
For unbelievers that haven't seen asm.js in action, checkout this famous demo that works well in both Firefox and Chrome: http://www.unrealengine.com/html5/ - that's pure JS right there and I don't think the limits have been reached.
Almost every device connects to the internet now, not just web servers. I'm not sure the mobile or desktop story is any better - there are known and unknown exploits for all the main platforms, the DRM is broken frequently, and once the OS is exploited it's very hard for an app to stay secure individually.
So I'd say the web is at least equal to that in security, and perhaps better as you can quickly push out fixes and are in control of the entire infrastructure, whereas app developers are at the mercy of their platform creator to roll out fixes or allow them to roll out fixes, which can take days or weeks for approval.
Really have to disagree. You start on a false premise that almost every device is connected to the internet.
In banking, insurance, governmental, education and medical spheres, there are hard privacy and secrecy requirements. Same goes for military - look what happens when they slip up. If you want to think about it - what percentage of the economy do these interests represent? I would say a large portion. So to my mind a large portion of the economy has a data security requirement that don't seem to be met by web apps.
In the consumer sphere, sure you can replace some programs with javascript, but can you see apple employee's using google docs at work? Why is that?
Also in corporate networks, they may be connected but through a proxy - which would reduce the attack surface.
There are air gaps and network gaps for data security. So your conclusion is based on a false premise.
If you're relying on air-gaps or proxies for security, the same applies to web apps, so I don't think this advances your argument that native apps are more secure than web apps - Intranets can host web apps too.
Apologies for side-tracking you with this irrelevant argument about connection to the internet - I was thinking of mobile devices specifically, which are almost all exposed directly, but you're right, there is a whole class of apps/devices which are deliberately kept off the public internet.
Actually I invented some technology that does this that we're using in production. Full two way integration between browsers and desktop and mobile apps. No plugins required as well.
It's that he thinks that the web will win (over app stores). I strongly believe that he's right there.
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.
"It's that he thinks that the web will win (over app stores). I strongly believe that he's right there."
"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.
I have to agree with this. It seems to me that people that think the web will win haven't tried deploying the same functionality via web and native app - the native app will be faster to develop and better.
Even Google seem to know this in their hearts. The Chrome team recently have started to acknowledge how far behind as a platform the web really is, and things like Google Now don't exist as websites at all.
The web simply has too many cases which don't work. For example, my current headache is the lack of wake lock style functionality, but the layout system is a trainwreck, the language tooling is abominable, and support for stuff like audio is a mess. All it has is ubiquity.
> "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."
Google hasn't tried deep integration of web apps with Android. Their competing Chrome OS does and Chromebooks are a bestseller in 2013. Mobile Chrome doesn't have "apps" or plugins, like Firefox does, which is kind of disappointing. "Add to Homescreen" of favorite links was added in version 31 and current stable version is 32, so that's one version ago.
The reasons for this state of affairs can only be guessed, but given that you probably don't work for Google and you don't claim to have insider knowledge, I guess that quoted phrase is just pure speculation - and a much more sensible guess would be that delivering a native SDK that works well was faster than trying to push for new web standards (since Android was competing with iOS and second to market) ... something which they are doing with Chrome OS and Mozilla is doing with Firefox OS and it's a very different reason than your claim.
And if I am to make a prediction, I bet that in the future either we'll see Android and Chrome OS merging, or we'll see Chrome OS mobile devices, in addition to Android.
> "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."
Web interfaces and offline access are not mutually exclusive. Chrome's offline GMail is pretty good these days. For PGP encryption in GMail's interface, I've been using: http://www.mailvelope.com/
Surely Chrome's permissions for extensions could be improved for better security, because as we've seen, perfectly legitimate extensions can turn over night to mallware/spyware/adware. And we would need new web standards for extensions and probably for doing client-side encryption, however these are not insurmountable problems. Either way, if you're using GMail, your unencrypted emails will get stored on their servers, whether you're using GMail's web interface or not.
> 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.
I don't like the insult inherent in this message. I'm using web GMail and I'm not an US citizen. The problem is that Google is an US company, not that GMail is a web interface.
And in regards to clients and native apps - my trust for binary blobs is equal to my trust for web interfaces, which is zero. Basically I don't trust anything that's not open-source and developed in the open - as in, are you sure your operating system doesn't have backdoors planted? ... just saying, seeing that you're playing the trust card.
I live in a suburb of Los Angeles where every kid in the school district has been issued a chromebook. this is the kind of market share Google will capture. For better or worse.
You linked to the HTML5 Unreal Engine demo to demonstrate that JavaScript is competitive with C. But Unreal Engine is not written in JavaScript. It is written in C++.
Do you mean to say that this is the future of the web: software written using traditionally native languages, delivered in a compiled blob that the user can't inspect, but that has good performance?
This sounds more like native software encroaching on the web than the other way around.
>and hide the difference between apps and web apps, and your mom won't care anymore
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.
It depends on your goals. If your goal is to do a startup, then the obvious choice is to really master an entire web stack. For instance linux / nginx / python / html / css / javascript.
If you want to do research in computer graphics, then you better learn OpenGL and C++ or .NET. Want to work in embedded systems? C.
Scott's recommendation of C# & Javascript is a solid and pragmatic choice, good for those looking for a safe career in software. But it's certainly not the right choice for everybody, and even 30 years from now there will be plenty of challenging opportunities that have nothing to do with the web or javascript.
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.
Agreed too for your opinion about how to do a startup. But I want to add C to your full stack suggestion. Sometimes it pays off to know low-level details about your choice of technologies. Almost every important technologies that I know is implemented in C.
I'm rewriting our Node.js based server in a combination of C and LuaJIT as we speak. The performance difference is absolutely astounding, in part because our Node.js app relies heavily on compiled modules, and the cost to cross from JavaScript to C++ and back is obscene.
The straight C implementation looks like it'll be over 1000 times faster for our use case, which involves tons of buffer manipulation and usage of compiled modules.
We're actually building on top of Snabb Switch[0], which is giving us another 10x improvement on beefier hardware (2x$2600 CPUs, vs the single socket, $800 CPU we're using now).
Our current engineering goal is 1 million full transactional, ACID-compliant writes per second, and 10 million reads per second, on a single dual-socket E5-2697 v2 box. That's a line rate (for our application) of just under 24Gb/second, which we're handling with a single 40Gb Ethernet adaptor.
Obviously, we did not think Node.js would get even close to this, but we did think it would at least work for a month or two for 10,000-50,000 users. Sadly, it's only got us through development and now that we've submitted the app to Apple, the server is being rewritten from the ground up for adequate performance.
If Node.js's performance had been closer, I probably would have spent time optimizing the Node.js server, but it's so far off right now that it's just not worth the effort. The Snabb Switch port is expected to take less than 10 days total (we're already 5 days into it).
For better or worse, the way we've been designing even high performance servers like nginx is just out-of-date. Intel made a huge push to replace custom, ASIC-based network processors with E5 Xeons, and the software development in the larger community just hasn't caught up yet.
Snabb Switch, for example, has a wire-to-wire latency, in LuaJIT, of just 26 nanoseconds. For reference, that's about how long it takes a photon of light to travel 25 feet. When messaging speeds are that fast, the Linux kernel is an enormous source of inefficiency, and even TCP is less than ideal (we use a UDP-based protocol with full public-key encryption per packet).
No doubt, knowing C always helps. gdb and strace work where other tools fail.
In order to be a well rounded developer you ideally have familiarity with functional programming, declarative programming, lisp, and a much more. You hit diminishing returns pretty quickly though.
Can you do without only Python and its framework for programming side? As someone new to programming, I find it mind boggling how folks suggest learning multiple languages. Or does it become natural after you know one language very well.
The thing with programming languages is that while they sometimes look very different cosmetically, they often share similar concepts under the hood.
IMHO, you won't go wrong learning one language reasonably thoroughly as a starting point. In fact, I'd recommend it for several reasons.
However, sooner or later, you'll probably hear that another language might be more useful for another project you want to do, and maybe then you'll learn that second language too. As you do, you'll notice similar ideas cropping up, even if they go by different names or use different syntax.
As your experience grows, you start to think of each programming language as being roughly in this family or that family in one respect, and maybe being like these other languages or those other languages in some other respect. You also probably notice more what still makes each language distinctive, whether it's a few idioms that make writing a certain style of code easier, or maybe a couple of unique features that aren't widely available in other languages that are otherwise quite similar.
In the long term, it's these distinctions that make it useful to know several different languages. Even then, most of the languages you know will draw most of their tools from the same toolbox, and learning when to use a hammer and when to use a screwdriver will be more important than which brand of hammer or screwdriver you buy.
To give you an example, after having programmed for years with PHP and Javascript, having learned many design patterns, and mastered a few frameworks, I picked up Ruby and RoR for one particular project and didn't have any major troubles. In about 3 days I was programming at full speed again.
It definitely is easier to pick up other languages once you know how to program well in one of them. You start to see the commonalities, the similarities in overall structure, and you can draw comparisons between the languages you already know and the ones you're learning. Learning the first language is the hardest, I'd say.
If you're looking to maximize your choice of companies to work at, one piece of advice could be to focus on front-end instead of back-end.
I'm equally proficient at front-end and back-end, but the last time I did a whole bunch of interviews, I advertised myself as a front-end programmer (since there aren't too many full-stack positions around).
Why? As a back-end developer, you're limited to picking companies that match a single one of the three broad back-end categories -- generally Java, Microsoft, or "open-source" (PHP/Ruby/Node/etc.) -- since any programmer is usually only going to be really proficient in just one of those. If we assume companies are split 3-way, you're instantly limiting yourself to 1/3 of possible companies.
But on the front-end, there's no balkanization. It's just JavaScript, JavaScript, JavaScript. It's not too hard to learn JavaScript and jQuery inside and out, and with some solid CSS experience, knowledge of good development patterns, and maybe a framework or two, you can interview practically anywhere.
Ah but then you get http://www.100percentjs.com/just-like-grunt-gulp-browserify-... (and HN discussion) ... of course, despite this, I'm in your camp. Even as I'm doing mobile and now learning modern/ISO C++ for cross-platform development, the strengths that originally got me hired were in web programming and you can always pick up enough to work with views in one of the big technologies, be it Wordpress/Drupal (sigh), Rails (half sigh) or more abstracted GWT/ASP.NET components. (meh)
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.
Today that makes sense. But the react guys (at Facebook) have a point, Angular (developed for LOB apps at Google) can be slow unless you write optimizations for update looping, etc. Eventually Angular directives might be better supported natively as polymer-style components (those are slower still now, and lack IE support), or Dart might rise in popularity, at least beyond that of Angular. And then you've Google Closure, which, like any company-sponsored project/library will get the job done but at the expense of some amount of lock-in, since these projects tend to already have lots of internal code to build with. I'm not sure the answer's that simple. That said, I agree that for today's mix of browsers, Angular has the best compatibility if you want more than React.js. Ember just took too long to settle down and still has oddities in data handling.
The same holds for C/C++. You can find a wide variety of companies that use it in one form or another. Plus, it's a front-end technology too :) And it is kind of a superset of Java or C#, so you are a good fit for very many jobs.
Your assessment of the emerging front-end skillset is spot on. For better or for worse, if js frameworks are here to stay for the next few years (and it seems they are), the programmers who got in early are going to clean up as they are now sitting on 1-3 years of experience.
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.
Seriously, jQuery > all the other "low-level" libraries out there combined, and Angular > all the other frameworks out there combined, several times over.
If you want to interview practically anywhere, learn those three and you're solid.
Angular > all the other frameworks out there combined, several times over.
Sure. But according to my in tray, last week it was Backbone, next week React is taking over the world, and by March we'll have standardised web components anyway.
It may be true that today Angular is much more popular than all the other frameworks, but if so, it will probably be a short-lived peak and IMHO says more about developers putting too much faith in frameworks generally than anything else.
But why would you want it to? It's likely to wind up being a leaky abstraction at best, assuming it survives that long, which is far from certain given Google's track record. If you want to be bleeding edge with web components, I would have thought experimenting with Polymer would be more interesting and give an easier transition to native features as they become available. If you want a more production-ready component-style framework today, why not use React instead of Angular?
Because JavaScript the language is so bare-bones, you need to supplement language deficiencies with frameworks and libraries.
Since when? It's perfectly possible to build web sites/apps, even large scale ones, using no framework at all. Pick a handy utility library, whether it's jQuery or Underscore/Lodash or whatever, and get coding.
I don't know where this idea that you somehow have to build web apps using some humungous framework came from, but I hope it relocates that rock and crawls back under it. In the history of programming, very few frameworks (as opposed to libraries) have stood the test of time.
If the point is to easily be able to find work (which was the parent's emphasis), then yes, you need to learn the popular frameworks. No, it's not required for building your own web app, but companies use them, so they'll expect you to be familiar with them.
Where are you based? It seems like in most places it's an employee's market right now (assuming you work for an employer). Given the diversity of front-end frameworks and how new most of the trendy ones are, I find it extremely hard to believe that anyone who's any good at front-end development and has a decent track record to prove it will be short of work any time soon, even if they don't have a full complement of buzzwords on the resume. And of course it's certainly not necessary if you're doing it for your own business or if you're consulting/freelancing and have your pick of tools.
Portland, OR. I think you're probably mostly right with regards to frontend development. All my experience applying for non-contract work has been for backend positions, and I know for a fact that I lost at least two potential jobs because I didn't have the right language/framework on my résumé. But just based on my limited searching for frontend positions, it seems like companies do expect you to know at least one well-known framework really well, even if it's not the one they use. So you shouldn't need to master all of them, but you should definitely be familiar with their patterns.
So you shouldn't need to master all of them, but you should definitely be familiar with their patterns.
I certainly agree with that. I'd expect anyone claiming significant front-end development skills to at least be familiar with ideas like MVC and data binding these days. I just wouldn't much care which specific tools they used to implement those things, and I wouldn't hold it against them if they'd considered their options and then chosen different designs and/or tools instead.
I am stuck in a hiring war-room for the last 2 weeks (two to go). [1]
We are using jQuery/EmberJS/Bootstrap/Grunt. Everyone of the FEs agreed that experience in any JS MVC was acceptable. [2]
So while I agree that it's not JS, JS, JS but it's not quite as bad as what you're saying.
--------
[1]: We were having a problem getting front-end people so they had managers put 15 front-end engineers on the task full time for a month. Our mandate is 30 engineers in 30 days.
[2]: sdumas [at] yahoo-inc [dot] com if your looking!
> We were having a problem getting front-end people so they had managers put 15 front-end engineers on the task full time for a month
I have never heard of a hiring war-room or lockdown of that type. Are you redesigning/improving the current process, or just interviewing people until you meet the quota?
both and. the talent acquisition folk were very interested in how the engineers went about finding people. they shared all of what we were doing with the other talent acquisition people at their all hands meetings.
lol, tons of reasons... a few off the top of my head; routes are central to EmberJS and are key to SPAs. AngularJS uses primitives as models which means that at the kind of scale we are hitting in our apps performance suffers (dirty checking 10k rows is killer) (also, computed props are easy, and we're into UAP). EmberJS' caching rocks.
But the big one is -- Google. When are they gonna pull the plug on AngulerJS, how broad is the contribution base outside of Google, and not using YUI was already a battle...
So... javascript, javascript frameworks, and javascript variants. I think "Javascript, Javascript, Javascript" was accurate enough. And Bootstrap is easy.
This idea that a software engineer picks a language as his "favourite" and becomes a "Ruby developer" or a "JavaScript developer" ever since is completely misguided, and I'm sad to see it cherished further in this article.
Languages are tools, and tools should be picked depending on the project: its application domain, performance requirements, availability of libraries for important subproblems that have been identified, target platform, etc., there are lots of very concrete factors to look into. Completely ignoring those factors in favour of choosing your "favourite" or one of just 2 languages you happen to like, is going to have suboptimal results. A good engineer knows a lot about programming languages in general (what is taught in a university "Programming languages" course), has basic experience with a huge number of languages, and picks the programming language for the project based on this knowledge, based on research and on prototyping, that's how I see it.
I recommend looking back at Marvin Minsky's 1970 Turing Award lecture "Form and Content in Computer Science". Little has changed since:
The trouble with computer science today is an obsessive concern with form instead of content.
Languages and frameworks are tools, but they're tools that require significant time investment to master and there are too many of them to master every one. There are many, many cases in which a given person's "optimal" language to use for the task is different than the "optimal" language would be if the user were somehow equally skilled in all.
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.
Becoming a "JavaScript developer" surely pigeonholes you, and that is not good, but early in your learning process it can be good to pick a bread-and-butter language to master first.
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.
The other nice thing about picking a "bread-and-butter" language is that it qualifies you for opportunities where you can leverage it to learn other skills. It's so much easier to learn, say, machine-learning if you enter a company where there are machine-learning experts that you can observe at work and ask questions of, rather than just trying to read all the online course material. That requires having something to bring to the table, and if you're really good at frontend stuff you can get hired at places that do that and work on projects where people are doing really interesting backend stuff.
If you want to point out that the way the world works is crazy - well, alright. But the rest of us have to make a living, and the way hiring works is that organizations hire in part based on your experience with a certain language or platform. "Well, they're doing it wrong". Okay, let's say I agree. Then what?
"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.
Ultimately these things are a matter of opinion, but as a developer who knows C#, I'm not sure I'd bother to learn it again if I had to completely reboot my knowledge. I can understand the perspective of being pragmatic with regards to the job market, but while there are an abundance of C# jobs available, offers tend to be lower unless you're specialized in Sharepoint or very senior. Culture can be a challenge in those shops as well.
"Professionally" I've worked the most with Python, JavaScript, PHP, and C#. Of those, I'd only keep JS and Python. I'd swap out C# and PHP for Clojure and C in a heartbeat. Probably not the best for job prospects but definitely the most fun.
"Ultimately, we're all amateurs." - Wow, that's something I've been thinking a lot lastly. It's true that a good developer can learn a new language (or technology, or even paradigm) in a quite short amount of time, but at the same time, when we're constantly doing that it's true that, as an effect and as the author says, we're becoming permanent amateurs. I don't have a solution for this though (maybe there is no solution at all, or maybe there is not even supposed to be a solution).
Its true.
To quote a wise man at the php conference "I get the feeling we're just making stuff up that works" when talking about scaling sites.
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'd actually recommend a slight variation on the C# javascript combo - Typescript instead. There are all sorts of tools coming out that allow you to generate Typescript interfaces from your C# giving you really nice compile time safety through your entire stack.
If you're writing C# then Typescript feels more natural, especially in Visual Studio it removes much of the painful context switching between a typed intellisense driven development and a javascript free for all.
I liked the idea of typescript but after frustration from fundamental issues I was very happy to bin it.
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.
I use pycharm with typescript, and either I have a new version or the pycharm plugin is far different to the webstorm one. All the refactoring options, jump-to-symbol, type hinting, type completion and inline-error checking work really well for me.
There are some pain points to be sure (modules, generics that don't quite work), but:
- Emits known good javascript patterns, preventing javascript's typical '50 ways of doing something'.
- Interacts cleanly and nicely with the existing javascript ecosystem.
- The emitted javascript runs on old browsers, and is only marginally bigger than the source code, smaller sometimes, if you use interfaces
- Clean module system (a little irritating to use perhaps, but still) supporting AMD and CommonJS (this is absolutely the future for JS dependencies).
- Open source, installable compiler using npm.
What's the alternative?
- native JS <-- Not a bad choice, needs discipline to maintain code quality
- coffee script <-- Interacts poorly with existing js ecosystem
- dart <-- Doesn't run on old browsers, poor interop
- emscripten <-- Massive output, poor interop
I cant say I'm any hurry to add C# into the mix, but typescript has impressed me thus far, despite being from Microsoft.
Really? Maybe I should have another closer look at it. I saw this from the homepage:
Embedded JavaScript
Hopefully, you'll never need to use it, but if you ever need to intersperse
snippets of JavaScript within your CoffeeScript, you can use backticks to pass
it straight through.
...and struggled to do basic things like interact with handlebars and jquery, and figured it was one of those 'works with other things written in coffee script' things.
Not so?
Why are there so many SO questions about 'how do I use coffee script with XXX'?
(where XXX is some existing javascript library, eg. jquery)
What specific problem did you have with jquery and coffeescript, or handlebars and coffeescript ,that's my question to you.
Coffeescript is a 100% compatible with javascript , the fact that you can embed javascript in coffeescript is a feature of the language,not a problem.
> I saw this from the homepage:
So what ?
> Why are there so many SO questions about 'how do I use coffee script with XXX'?
How does it mean coffeescript has compatibility issues with javascript ? You are just bashing coffeescript without any real argument against it. There are arguments against coffeescript , compatibily with javascript is not one of them. You dont know coffeescript. If you knew CS you would not have these bogus arguments against it.
Coffeescript fixes Javascript bad parts , Typescript doesnt,it just add a few keywords and compile time type checking to the language, which is unecessary.
Typescript on the other has compatibility issues with javascript libraries since one needs ambient declarations to use 3rd party libraries, some extra work not needed with Coffeescript.
Can you give an example of Coffeescript interacting poorly with the existing js ecosystem. I've seen complaints about the need for a build step, but since it compiles down to vanilla javascript, it works everywhere JS does, and its not hard to mix the 2 on a project if necessary.
GWT has been doing this for Java for years and works very well. In fact I'd jump ship to any technology that can do what GWT does, i.e. a solid server-side language that you can also write the client in, with a large mature ecosystem. Keeping an eye on Dart.
The Functional Reactive Programming paradigm is going to hit hard. It makes parallel programming extremely easy, which is a huge bonus for multithreading (a great way to harness multiprocessors) and for loading web pages asynchronously.
Libraries for this programming style are being created for almost any popular platform, and knowledge is spreading quickly. I recommend following some tutorial or online course on the subject.
The sweet spot for Bang for the Buck, for a typical programmer, would be Go -- then use it in a functional style. (Except for in strictly delineated circumstances, the entire code base should have zero side-effects outside of the current function scope.)
This gives you a safe, easily concurrent language, plus most of the benefits of functional programming, but without as shallow a learning curve. (Meaning not as hard. Learning curve is not an analogy for a steep road! Height = stuff learned!) You also get very good debugging. (gdb and cgdb in particular)
I'm writing my current project in Clojure, however, because it has most of the advantages of the above, but the available GC technology for the platform is far superior. (You'll have to learn some new debugging tricks, however.)
If you're in the US, learn whatever the hell you want. Then move to a biggish city and find a job using it. Bam, you are now equipped to take advantage of the biggest tech boom the country has seen since the 1800s. The 90s wishes they were this good.
I've been doing ColdFusion for well over 13 years now. The reason I choose it was because at the time the only other web technology that looked promising was ASP and I _hate_ Visual Basic with a passion. Today I'm focusing all my attention on C# and Ruby.
That all said, if I had to start over today... I wouldn't be programming, I go back to networking. As much as I love programming, it just doesn't amaze me anymore. I guess its the lack of physical interaction. I'm starting to dread typing on a keyboard for a living.
I look at all my friends in networking and see all the cool toys they get to play with and want to jump in the sandbox.
The new keyword is SDN I guess - software-defined network. A lot of what was the standard in networking and hardware domain is migrating to software now. Especially when you're running many dynamic virtual hosts, you may want to move the tricky networking parts into easy to redefine software configuration on the host itself.
This idea will get only more popular soon. Of course there are also products that allow you driving the physical boxes remotely - like openflow. I think the mix of those technologies will get quite important in the future. I'm not sure if that's what the GP meant though.
I think Virtualisation, Automation, and Orchestration technologies would be the best place to start again. I've seen some really impressive things done at pretty impressive scale with this stuff.
If I could start over and pick one language, it would be Java. If I could pick two or three I'd add Python or Ruby but let's stick with one.
Everyone knows Java is great (or at least pretty good) for "building large systems" like the article said. You can learn a lot about software engineering from all of the practices that have built up in the Java community over the years. Note that I'm not talking about gross JavaEE stuff, but just good, solid OO programming with an incredible about of libraries for whatever you need.
The real reason I'd push for Java is Android. Android programming is an incredible way for a newcomer to get non-trivial code in front of a large audience in a production environment. Writing an Android app has a decently steep learning curve, but once you get the hang of it you can really make progress quickly. Then you can publish to the Google Play Store with no app review, no $99 fee, and no Mac required. You'll get some downloads and real feedback on almost any app.
The first app I ever made was a total piece of shit and it got 50,000 downloads. It had a ton of bugs that people asked me to fix and it taught me how to make something that people actually want in an environment where I had nothing to lose. Even ended up making a few hundred dollars on ads which 18-year-old me thought was pretty damn cool.
There is an intoxicating feeling when you realize that a few hundred or few thousand people out there are running your code in their pocket, and it makes you want to create even more. It's the same with iPhone/ObjC I'm sure but I think Java has more other uses and Android is definitely a less intimidating platform for a beginner to just put something out there.
1) Any high-level language that runs in the Java VM. Because 1) there's tons of open source libraries 2) syntactic sugar for devs 3) operational stability of the VM 4) flexibility of running it on both open source and closed source OSes meeting a variety of business requirements.
2) A scripting language for gluing your operations together, for quick and dirty services, prototyping, etc...: Python
There was a very recent post here on HN about the way chrome guys wanted to add support for shadow dom features so fast that people in the w3c asked them to at least write some specification first. That post made me think that the web isn't going to win over native for mobile before at least two years, if not more. The specification process is both compulsory for the web to simply "work", but it's also very cumbersome.
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.
The web will persist. But it won't win anything. Nor will native apps win anything. With time we will finally accept "the right tool for the job" stance and stop forcing round pegs into square holes.
It's not necessarily a conflict that has an end. Because web-based stuff is standards-based, you'll always have a lag between state of the art and what is available in a standard. IMO, that's a good thing -- it pressures the market to continue innovating.
People at Netscape were talking about the web displacing native applications twenty years ago. That hasn't happened yet!
I want it to win, but I'm not knowledgeable enough to gauge the accuracy of such a claim. To me, it seems the largest of native mobile apps on any platform have a web component of some sort.
I'm in favor of application logic living on the web, with native apps used on the frontend for consumption.
You could "learn cordova" but you'd have a massive gap in your skills. As the website says "Apache Cordova is a platform for building native mobile applications using HTML, CSS and JavaScript", i.e. you still need to lean HTML, CSS, Javascript and a backend technology.
Discoverable, searchable, updatable, all the good qualities of a web app with the power and speed of a native app.
Of course you need HTML, JS, CSS and the whole web stack, but the good thing is everybody already knows it. Standards are good.
Apache is behind it, also Google, Firefox, Ubuntu, everybody benefits from a standard way of developing apps once, but very specially users, and coders.
It has to be the future, it will be no matter what, no barriers will be high enough that a great idea can not overcome.
"good thing is everybody already knows it" - so you recommend to learn something everyone else will know... I guess differentiation on the job market is not a part of this strategy.
"everybody benefits from a standard way of developing apps once ... and coders" - my feeling is that it's 50% of HN spirit is building things in different ways. Just look at all those awesome languages, libraries and frameworks coming out every week!
My opinion on "the web will persist and the web will win" is that it's not a won battle. Native apps have always been smoother, giving users a better experience overall. On the contrary, mobile web apps have been bad, and haven't much evolved since we started having mobile devices (laptops don't count :p). I'm pretty sure that the future resides in mobile devices, and they can't rub the web, we'll have to use the alternative: native. At that point nothing stops Apple or facebook to go entirely native and therefore abandoning the web ideology (and the physical web). So I think that the web is a possible future, but nothing is settled yet, we need more groundbreaking ideas from the web to make it a desirable choice of future.
I think there are too many smart and capable developers in the world to settle on old poorly-upgradable languages for everything. So hopefully there will always be a choice.
I would have thought that learning two languages at the same time.. especially with one of them being javascript would be a bit of a brain overload.
I would just suggest sticking to javascript to start with. You can do front end, node and mobile. With that under your belt you would then be in a much better place to jump to a different server language and would know more about which one would be the best fit for you. But focus on one thing at a time, you'll learn much quicker that way.
You mean ABAP ;) Actually SAP is at a very interesting crossroad right now. You don't have to know ABAP anymore. If you can leverage SAP Gateway and check out OpenUI5 - http://sap.github.io/openui5/ you can make a name for yourself. There is heavy demand for this area right now and not enough supply.
EDIT- If anyone is interested in this area, let me know!
I'm a current python/ruby/javascript contractor interested in getting into SAS/ABAP consulting and development. Do you have any recommendations where to start?
Basically SAP has put a lot of effort into taking it's old archaic back-end and making it "open", and Gateway enables backend systems like ERP/CRM/etc. to be able to talk to any RESTful front-ends (mobile, js, etc).
I would learn (as someone who is interested in backend stuff - scalability, high-performance systems, apis) related to web-work:
- HTTP
- C (because it teaches you how computers work a bit)
- One of the new JVM languages (either Clojure or Scala, preferably the first)
- some bash (for scripting)
Realistically that is a lot to learn in a year.
On top of that I'd start dabbling with Javascript but not expect to learn it this year (that's for next year).
If I could do it all again, I'd study a lot more math in University and probably end up focusing on something like Audio DSP. I think it's a pretty safe career choice since it's hard self learn compared to a lot of other fields, meaning competition is less. And if you are good, companies will happily pay you to learn tech of the week.
Once you know C, you've already gone through most of the pain with regard to C++s warts, but you still have to treat it as a new language.
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.
I don't mind the C++ that is "C with objects". What bothers me is the broken template metaprogramming, endlessly varying kinds of special pointers, massive libraries that does the same things slightly differently and so on.
"endlessly varying kinds of special pointers" haha that made me laugh thanks! I had never noticed it before!
TBH, although Bjarne in his most recent book heartily recommends using references everywhere and smart pointers, I seem to be throwing pointers around with no problems.
The RAII approach and clean up in the destructor is the safest way to do things in C++, and the tidiest!
I would have great difficulty moving over to C to think of a way to write a program, so it is comforting to find someone who would struggle to move to C++ from C. They really are different beasts.
You cant learn Typescript without learning how Javascript works.
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 know you need to at least have rudimentary knowledge about js in order to use typescript effectively. But I think I already do (I just don't want to learn more as it makes my skin itch). More likely I'll just give up on the entire thing and wait until ES6...
Yes C and Rust (and C++) overlap a lot. C is inevitable for a lot of embedded and low level stuff, but for large scale systems dev I hope to see Rust replace C++.
Python is multipurpose and has great libs, but personaly I dont like the language itself. I think Ruby is a better designed language , but Ruby has problems too. Unfortunatly the perfect language + ecosystem doesnt exist.
Understanding APIs around bitcoin and cryptocurrency in general seems important.
I believe that the internet is eventually going to be switching away from normal named server structures to a content-oriented architecture. http://en.wikipedia.org/wiki/Named_data_networking There are a lot of ways this category of architecture is actually currently being deployed behind the scenes, for example CDNs or bittorrent. I believe that we are going to start using that type of system more and more and eventually we will lose things like the HTTP layer. This may be combined with some of the technologies related to cryptocurrency.
For an example of why we are moving to named data networking, take a look at well.. just about any web application that wants to scale. For example the npm registry. Also consider the issues around privacy with Facebook and the NSA, and the ability for governments to censor or take down web sites or domains.
So any technologies that facilitate things like that, such as more traditional clustered SQL or NoSQL tools, or especially protocols and systems specifically designed for named data networking, will be very powerful. I like the idea of heterogeneous peer nodes that have everything they need built in and can connect to the network on their own.
Another area that is really going to be key is artificial general intelligence. Notice I did not say machine learning. I think look at taking advantage of built deep learning systems like the one IBM has with Watson. Or look for deep learning, autoencoders, hierarchical hidden markov models, hierarchical temporal memory. But most practically for the next few years IBM and Google's (when Google releases it) cloud AIs are going to be game changing for many industries and harnessing them in software will be very useful.
Qualcomm/Brain Corporation and some others also have some neuromorphic chip technologies that could be extremely useful.
Any system that really takes advantage of next gen VR devices like Oculus Rift is going to be interesting.
I've never heard anybody mention Angular and Web Components as solving the same problem. I'm pretty fuzzy on front end MVC stuff in general, but I know almost nothing about Web Components. Do you know of any good tutorials or resources?
Reusable components along with two-way data binding are the most important features of Angular. Web Components does components in a more product neutral, standardized way with a nicer API. Creating custom directives for elements in AngularJS is a pain.
To start over again, I'd have had a much bigger focus on standards and open-source, standards-compliant software. Having been spoiled by Visual Studio, I now lack the patience necessary to setup a dev environment from scratch with Emacs or Vi or whatever.
And no, Eclipse is not an alternative, though maybe NetBeans is, which are two statements I really wouldn't have said 10 years ago. I don't really feel like it's a case of Visual Studio having gotten significantly better. NetBeans has gotten significantly better and Eclipse has gotten significantly worse. MonoDevelop and Xamarin Studio are waaaaay too buggy to be useful. I find myself gravitating to a text editor like Geany or really anything that combines syntax highlighting, tabbed documents, and a file explorer. It's amazing how infrequently those three things come together (I'm looking at you, Notepad++ and Notepad2), or just don't work very well (Hi there, LightTable and DrRacket).
While I like C#, the promise of quality cross-platform software with it is mostly a boondoggle. The hoops you have to jump through, and the state of the dev tools for Mono, just push me towards Java anytime I need a cross-platform desktop GUI app.
And that's sad. Because it's not like Java does a particularly good job of it, it just does a site-better job of it than most anything else. I don't have a good enough handle on the C toolchain to pick up and run with Qt or GTK and cross compile for every platform. And nobody pays enough attention to desktop in basically any other language.
Please, correct me if I'm wrong, because I'd really, really like to be wrong here. I suppose I could do [Pythong|Ruby|OCaml|Haskell|Racket]+[GTK|Qt], but it feels grating. It doesn't match. As far as I can tell, there is no GUI library that works well in functional languages--even a wrapper on top of an OO one. But again, correct me if I'm wrong. Please.
Other than that, I wish I had ditched SQL Server a long time ago. Postgres is just as easy to install and use now, and has been for several years. I wish I had the balls to replace my clients servers with Postgres and just not tell them about it. They probably wouldn't notice.
I wish I had never wasted time on Python.
I wish I had kept gaming to my Playstation and stuck it through with Linux back in 2000.
I wish I had not gone to college. Going to college meant I had to get a job that paid well to service my debt afterwards. And for where I lived, that meant I had to buy a car. Even still, being 22 years old and having only $35k in debt was far better off than most of my peers, and even better still than most of the kids graduating today, so I guess I'm not too badly off. But still, I think about the last 10 years and really wish I had been writing all of that software for myself rather than The Man.
What the hell was the point of writing all those projects in college for the command line? 4 years of wasted practice on an interface only other programmers care about. It is such a fundamentally different paradigm, and most of my peers didn't transition well. I didn't transition well, and I've been either the most successful person or at least in the top 3 of my graduating class.
I wish I had never stopped doing screwy shit in JavaScript. There was stuff I wrote in 1997 that people are pushing today as "the power of HTML 5!" If I stuck with it, instead of listening to my "betters" at work or in college, then I think I could have contributed a lot more.
So, less about what specifically I would have studied, and more about not listening to what others have to say about what I should have been doing.
"Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author."
A Microsoft employee talking up C#, what a surprise.
At some point, app stores had "discoverability" as an advantage over the web. This has been one of the strongholds of native app proponents. These days however, with the enormous amount of apps available on popular platforms, this discoverability feature has become a joke. It's akin to searching the 1999 web for interesting sites but you can only use a badly managed, bribe driven version of Yahoo.
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 only need 1 major mobile OS to change paradigm and hide the difference between apps and web apps, and your mom won't care anymore. Given that the world's #1 mobile OS is made by the worlds #1 web company, this change is not difficult to predict.