Ask HN: Where do you see web and desktop apps in 5 years? - <AUTHOR>

As the browser becomes home to more and more software that traditionally would be desktop only, where do you see web apps and desktop apps in 5 years? <comment><USER2> Hopefully 5 years is long enough for us to stop and take stock of the inevitable destination of the browser: an OS in a VM.

With any luck we might finally realise that we're not dealing with "documents" anymore, that HTML, JS, and CSS do not a good UI framework make, and that JS simply isn't good enough for what we need it to do and how we need it to do it.

ECMAScript 7 will be pretty much ready to implement and the standards committee will realise that they've run out of syntax for ECMAScript 8, forcing a rethink. Fingers crossed a neckbeard will arrive and point out that a LISP would be ideal for both defining the "DOM" and providing a base language for targeting by other languages, who can just (ok, "just") serialize their ASTs and pass it in.

Seriously: if, in 5 years, we're still perfecting the dominant user-facing runtime by tweaking an arbitrary XML spec, a language with only one kind of number, and a styling language so inept it almost _requires_ auto-generation tools, well I might just kill myself.

<comment><USER3> After doing web for a little bit, ending up loathing it, and then checking out iOS and enjoying it so far, I couldn't hope for this outcome more. I never realized how crippled browser based web applications and the ancient, shitty tools used for creating them are before developing on a web-connected platform that uses a systems language directly for its applications. Pretty much anything you can do with a computer, you can do in an iOS/Android app, and it can connect to the web, which lets you create rich experiences far more easily. To make any modern web application for a browser, you have to use garbage like opinionated JS frameworks and a myriad of other crutches and hacky solutions because the tools for the frontend are incredibly limited and were not designed for what is demanded of them today. Plus browsers don't easily support connection protocols other than HTTP, so this leads to a whole other host of hacky backend solutions for developing so called "real-time" applications, when you could easily use something like UDP were you not limited by a browser. Only downside to iOS/Android platforms is that they are governed basically by the Apple/Google dictatorships(which is somewhat understandable, because it would be a disaster if anyone could so easily distribute applications widely capable of executing malicious code on a user's device), and it is completely up to them what is allowed and what isn't, in contrast to the open nature of the web. I don't know how this could be remedied, seeing as there is an undeniable trend of more and more consumer- facing web activities being done through mobile apps, rather than browsers. Something like a completely FOSS device OS with a decentralized marketplace; e.g. anyone with a server can host their application, similar to how it is with jailbroken/rooted phones? This still wouldn't solve the problem of people being able to execute malicious code on a user device, but I guess if you think about it it isnt much different from some idiot downloading "free cursors" from some malware site and giving themselves a virus like what happens all the time today.

<comment><USER4> Really? Web technologies are much easier to work with and make a much better UI toolkit. Just look at the share amount of developers doing Web stuff and compare them with the amount of developers doing iOS.

And btw, iOS development is easy for as long as you do not want to customize things. Once you start changing the standard controls you are entering the land of no return.

Now compare this with web technologies which are designed to be customizable.

<comment><USER5> > Just look at the share amount of developers doing Web stuff and compare them > with the amount of developers doing iOS.

I think that is more because web apps can reach a much larger audience, not because web apps are easier to develop.

</comment></comment></comment></comment><comment><USER6> Same place we were five years ago: nobody cares what API you're programming to as long as your apps are good.

No, seriously. The iPhone SDK came out in 2008. Google Maps came out in 2005, ushering in the modern era of web apps. Mac OS X came out in 2001 and .NET came out in 2002, representing the major desktop platforms we know today.

The web as a platform is no different than any other platform in that it's just another platform with its own strengths and weaknesses. It just moves a whole lot slower than the rest, which is why we're still asking this question after this many years.

APIs and platforms come and go. Developers always have had and always will have choices about which ones to pick for developing their apps against. These choices have some impact on how easy it is to build various types of apps, but at the end of the day, the only thing that matters is how well your app serves the needs of those using it.

</comment><comment><USER7> I don't think things will change a great deal in 5 years. I would love to be wrong, but the progress of web standards and browser technology is painfully slow. The things at the leading edge of development are amazing, but there is an enormous gap between the first browser supporting something and being able to assume that most users will have support. There is also a very slow progression due to the rather annoying notion that everything must have a 'Use Case'. WebGL comes along and when that got into browsers the need for Typed Arrays became more evedent, once people started making games and so-forth they wanted fullscreen options once things were fullscreen people wanted to use mouse movement rather than mouse pointer position so that FPS games could work properly. Each advance demonstrates a new deficiency which gets fixed but it takes another iteration of browser development and release.

I think the change is coming, it's just that the timeframe of 5 years is just too short.

I started a project a few years ago aiming to do Desktop style things using HTML+CSS+JS. When I started I was just mucking around and I expected something better to come along and I'd abandon the project, but I'm still plodding along ( [https://www.youtube.com/watch?v=7namj7iy16Y](https://www.youtube.com/watch?v=7namj7iy16Y) ).

Along the way I came across a simple idea as a test of whether or not WebApps were up to the job of desktop work. Completely replace the functionality notepad.exe (or OS Specific equivalent level program) with a Webapp. The text editing part is easily managed, but the test is not for what can be done but what can't. What about opening all .txt files with it, editing then saving the result to the desktop, or hacking on startup scripts when nothing else is available?

Much of the behaviour of WebApps assumes that "It's on the Cloud". That is a Deal breaker for a lot of people. Especially since Snowden.

We're getting there (or at least somewhere) but we're not doing it terribly quickly.

</comment><comment><USER8> A related question might be: where will mobile apps be in 5 years?

Hopefully, the answer is that web standards will evolve to allow HTML+JS to do things currently only possible in mobile apps. This would mirror the original transition of desktop apps to web apps, and would have positive implications for the internet by bringing mobile users back to webpages (though I wouldn't count on it being done in 5 years).

<comment><USER9> And its corollary: what will devices look like in five years? How big will they be? And how will be people be carrying things that big?

<comment><USER10> I was shopping for phones today and physically they're all bigger than my almost five year old iPhone 4. The user interfaces are essentially the same as on my iPhone or my even older G1.

I did see a curved smartphone for the first time though, so I predict in 5 years phones will be semicircular, about 40% larger than they are today, and have slightly faster graphics.

<comment><USER11> Going totally off topic here, but if you're willing to try something different than iOS then have a look at the Sony Xperia Z3 compact. Small (by todays huge standards) but packs a good punch in specs :)

</comment></comment></comment></comment><comment><USER12> _More voice control_

No I don't like yapping at my phone or PC, but my 6yo kid loves FireTV's voice search feature and uses google voice search all the time on her iPad, even if she knows how to spell the words. As precision improves, I see my wife is using it more too, for searches and dictation.

 _More support for device- /screen-hopping (state-in-the-cloud, continued- commerce)_

 _Stick-computers_

Affordable devices optimized for streaming screens/desktops/apps hosted in the cloud. Hardware upgrades only in data centers. Consumers investing instead in high bandwidth/low latency connections.

 _Web 3.0 == forgetting (ignoring /hiding)_

More apps featuring some form of 'forgetting' (hiding older, unused, unimportant, noisy data).

More apps assisting in the reverse: new mechanisms to improve recall/precision of 'forgotten' information by 'priming' our searches with user input (sounds, locations, colors, images) and/or interactive feedback (hot/cold, before/after, similar/different, binary search)

<comment><USER13> This also comes back to hands free for driving, etc. I don't understand why a tesla d can drive itself but we're still using blinkers and manual actions to change lanes...

<comment><USER12> This may be in our near future as well. Did you see the Audi R7 piloted driving stuff?

Check out [https://www.youtube.com/watch?v=eOYsI1cqUrw](https://www.youtube.com/watch?v=eOYsI1cqUrw) or the long version [https://www.youtube.com/watch?v=DeWriarFlsU](https://www.youtube.com/watch?v=DeWriarFlsU)

<comment><USER13> Yea, so fucking cool. Also worth noting that this was on a closed course with a known track... That makes everthing a lot easier.

Update: I never saw this video, very cool thanks!

</comment></comment></comment></comment><comment><USER14> Software above the level of a single device.

Data is replicated, no item exists only in one place.

Data is shared, shareable and in formats that can be operated on both by the owner and by the user, the visitor, the renter, the spectator of the items in question.

Data is encrypted, watermarked, tagged, associated to immutable provenance histories.

Data is ephemeral, guaranteed to be forgotten, subject to erasure, intended to be unrecoverable once used.

The network is reliable. The network is unavailable. The network is on the side of the people. The network will stab you in the back when you least expect it.

Some programmers will insist on writing javascript to control medical devices. Some programmers will insist that casual games running in sandboxed environments be provably correct.

Someone will cobble together an AI and set it to rewriting enterprise java apps, when interviewed after the disaster the AI will claim that humanity "had it coming".

A software bug will start a small war. And a EULA clause will end another one.

You will be completely transparent and documented for everyone else to see. You will not have sufficient permissions to find out anything about anyone with any power over you.

Most applications will incorporate blockchain technology; but bitcoin will be the subject of jokes and nostalgic pop culture trivia questions.

It will be the best of times ( for some ), and the worst of times ( for others ).

</comment><comment><USER15> Desktop and mobile and web will continue to converge. That trend is already well underway. You would not go wrong by developing for the web, if you want to build to be relevant five years from now.

About half of the high end and mid end laptops have touch screens now. More will have them next year. The year after that, it'll be impossible to find a laptop without a touch screen. Touch will become pervasive, as it is how kids are comfortable interacting with devices and a lot of current kids will be adults in five years.

JavaScript will continue to evolve and find its way into new places. While Firefox OS probably won't make a dent in ChromeOS or iOS market share, the paradigm of developing mobile/desktop apps using web technologies probably will expand. It's hard to argue with tech that allows building run-anywhere applications.

Performance of browsers will continue to approach desktop native performance, further allowing more applications, including some that are currently impossible in-browser, like good 3D games. Native games will be among the last types of app to go browser, but they will come along, as well. The browser VM is pretty good and getting better. Unity has already shown that a lot of games can be built in a VM language and environment (and while Mono/C# is currently faster than JavaScript for some things, and has more native access, that likely won't be forever, and increasing machine performance will likely close whatever gap remains).

Assume everything will be more powerful, and things that are just out of reach today because of memory, or CPU speed, or disk space, will become mundane in a few years. Maybe not five (Moore's law has slowed, as has every other "law" about increasing computer performance, but it has not ceased), but in a span of ten, the difference will be huge. So, when someone says you'll never make a great 3D game on a table running in the browser, you should assume that really means, "you won't make a great 3D game on a tablet in a browser _today_ ".

Network speed will be a continuing source of revolutionary change. Fiber is making its way slowly, but surely, into the home. That kind of speed changes _everything_ about how you interact, just like broadband brought us YouTube, GMail, Netflix streaming, streaming every kind of media, etc. fiber will make it seem entirely normal for every file to be stored in the cloud. We're nervous about that, as nerds who understand the privacy implications, but it'll happen, whether we trust it or not. Just like facebook continues to happen, despite our misgivings about what a privacy nightmare it is. So, building good encrypted ways to use that incredible network will be an ethical and profitable way to predict and create the future. (Building un-encrypted ways to use that network will be evil, but profitable.)

<comment><USER16> this. Convergence of everything on HTML/JS/CSS and the continued evolution of those technologies.

and we're overdue for a bandwidth upgrade. The NBN in Australia is slowed by politics, but not dead and people are beginning to realise how awesome it actually is. The same I gather for Google Fiber in the USA? Are there any similar projects in Europe? Elsewhere?

<comment><USER17> There's a similar project under way in New Zealand, but from what I see, the uptake has been less than enthusiastic due to lack of online services like Netflix and persisting traffic caps.

</comment></comment></comment><comment><USER18> Developers will view REST APIs with the same dismissive disdain reserved today for SOAP/COM/CORBA. In 5 years time there'll be something much cooler, probably based on GIT. (GIT will live forever.)

The hot in-demand skill will be writing tight C code for ASM.JS based single page holographic apps.

We will commute in flying cars and poverty will be history.

Or maybe not - who knows? The best way to predict the future is to invent it. Nobody has a crystal ball, so it's really up to you.

<comment><USER19> > The best way to predict the future is to invent it. Nobody has a crystal > ball, so it's really up to you.

In a sense you're right, it usually takes a few people doing something different, and if it's better, others will follow suit. However, by following current trends and looking at how past trends played out, I'm sure we can have a reasonable idea of what will decline and what will gain favor.

As the OP already noted, we can already notice a move towards web apps. Based on that one might conclude that we'll all be using web browsers as our OS and Chrome OS is a perfect example of that. However, we should also notice that demand for desktop apps didn't suddenly die out as web apps gained popularity. Desktop apps are still in demand, so the previous conclusion is too hasty. One conjecture I want to make based on current trend is that developers will start developing more for mobile platforms (phones and tablets), rather than the desktop because this is where consumer demand and use is moving to.

In both cases we can use current trends to strengthen or weaken hypotheses. It's not like the future happens in a crystal ball either, yesterday was another day that contributed to the future.

</comment></comment><comment><USER5> Here's something a little out of left field, but worth considering: By adding support for Android apps, Google Chrome has the potential to completely dominate desktop and mobile development.

Using a simple hack [1] it is already possible to write a single Android app that runs on (a) Android tablets; (b) Mac computers; (c) Windows computers; (d) Chrome OS computers; (e) Nexus Player set-top boxes. If Google were to put its full weight behind this strategy then I think it would quickly become the default platform for desktop development and thereby destroy the Windows empire. It might even mean Android apps being developed for what would normally be the domain of web apps.

[1] [http://lifehacker.com/how-to-run-android-apps-inside- chrome-...](http://lifehacker.com/how-to-run-android-apps-inside-chrome-on- any-desktop-op-1637564101)

<comment><USER20> I don't remember which book it was (maybe "Inmates are running the asylum"), but there was an example of dancing bear. It is amusing to see that bear is able to dance at all, but that is by no means are good dance.

Also, how many users are constantly switching between different platforms? If all I see is the lousy app on my platform of choice I could not care less about its capability to run on others platforms.

<comment><USER5> A similar quote I read was "A horse that can count is a remarkable horse, not a remarkable mathematician".

You are right that users don't care about having one app running on multiple platforms. Instead, it is the software developers who would benefit by not having to write the same app three times.

You seem to be assuming that an Android app running on a non-Android platform would be 'lousy'. Is that because an app designed for a touch-based tablet would provide a bad user experience when run on a desktop computer?

</comment></comment></comment><comment><USER21> >>As the browser becomes home to more and more software that traditionally would be desktop only

Sorry I don't see that. All of my desktop apps are still desktop apps. On Windows I still use Office, VS, Adobe CS, Amira.

I don't see this happening any time soon due to legacy codebase as well as performance and ease of coding issues. For example, with great difficulty one could port Photoshop, perhaps using clever off-screen WebGL buffers to do the heavy computation, but why would you do that?

<comment><USER22> There are plenty of Photoshop-inspired apps that run in the browser already. None of them are on par with Photoshop obviously, and maybe none will be in 5 years but I don't think it's completely unrealistic.

There are a bunch of obvious advantages to webapps like no installation, settings are kept no matter which computer you are working from, works everywhere, etc. They may not outweigh the disadvantages in your view but it does seem to be the trend in the world.

<comment><USER23> Do you think it's technically possible to get something on the level of Photoshop with performance that is, at least, acceptable enough, in the browser? Using asm.js I suppose?

<comment><USER22> I don't see why not. I won't make any guesses about a timeline, but it seems inevitable to me that it will happen at some point or another. Current technologies allow you to do quite a bit locally and it might even make sense to offload heavy expensive operations to a server instead.

<comment><USER23> Ah, sorry, I meant to ask if you think it's _currently_ possible with asm perhaps, considering that we can already do quite a bit of heavy stuff in js right now. I have no doubt over time it will be doable, I'm just curious if we might already be there (purely technically, of course, I can imagine we might not have the right tools to actually pull it off right now).

</comment></comment></comment></comment></comment><comment><USER24> The dream of "convergence" will reverse starting with windows 10. Web and mobile will tend towards html5/js, desktop applications such as browsers, games, ide:s, media production, cad,... will remain heavy C++ (or possibly Java/.NET) applications. In 5 years we will see no dramatic change in the landscape. People will realize that even moderately complex applications should never be browser based and ideas such as browser based word processors or drawing programs will be remembered as a fad.

Rust will ease the pain of heavy desktop development somewhat. C and C++ needs to retire, but that won't happen over night. It will take 30 years, not 5.

Web dev will be helped by ES6, or even better: AtScript/TypeScript. JS becomes the assembly of the web and hopefully no one has to actually write todays JS directly.

</comment><comment><USER25> I see everything moving to a ChromeOS-like model, with HTML+JS and WebGL for graphics-heavy things. If not those technologies in particular, something equivalent.

Essentially the consumer OS will be reduced to being a platform for a browser (I use "browser" loosely here -- I consider iOS to be an app browser in this sense). The OS will disappear from visibility.

To make this work you'll need a lot more standardization on APIs and data formats (because in the future consumers won't touch "files" anymore). I also think that's coming.

Finally, I see the server/client sides being even more divorced from each other. Clients will become dumber (single-purpose) and servers will become smarter (multi-purpose), and both will be much more connected.

</comment><comment><USER26> I've thought for a while that certain web technologies that Google is developing or promoting (e.g. WebGL, NaCl/PNaCl, V8, Chrome app store, Chromebook, etc.) has implied a vision of web apps being just as capable as desktop apps, perhaps even in categories such as video games that need raw access to the CPU/GPU. However, progress towards this vision seems to be going much more slowly than I would have expected, and desktop apps will no doubt continue to fill certain needs and niches even if a fully realized web platform is achieved.

Of course, mobile apps (and the consumer electronics revolution that has allowed many people to consider their phone as a primary computing device) are also competing in this space.

</comment><comment><USER27> IMHO, Prediction of software sustenance depends primarily on following points: a) Current Usage b) Current set of users c) Availability of internet d) Kind of exposure to apps

Current Usage: Current desktop apps are used by the majority for purposes such as documents, presentation, image modification, watching videos. If these purposes are served in fullest and flexible enough to adopt, then web apps will start dominating.

Current set of users: By numbers, if we go, majority of current set of users for desktop apps will fall in the category who might not be aware of a browser turning to be a replacement for all their needs. It will take 5 years for web apps to expand and become popular enough and reach out to this majority for extinction of desktop apps.

Availability of internet: Currently desktop apps are predominantly used for offline purpose, since connection to internet is not required. And places where there is no connectivity to internet is present, still desktop apps would survive. But web apps requiring internet connectivity at all times for each request-response will not be able to reach out to places where there is lack of internet connection. Web apps will need to provide a offline environment similar to desktop apps, then web apps would dominate. Otherwise, if internet connection is provided to everyone like how sun provides light to every corner of the planet, then web apps would burn down desktop apps.

Kind of exposure to apps: Currently, majority of users tend to sit in a cubicle and perform work, which is more related to desktop apps. If majority of users tend to become more mobile, for example, all the personal PC boxes become tablet/iPads/smartPhones then web apps (mobile apps) would need to replace desktop apps.

</comment><comment><USER28> I think about this a lot, part of my job is designing mobile apps for Ubuntu touch that scale to tablet, desktop, TV using the same code base (but different layouts). We are working towards convergence and the native Qt/QML apps we build for mobile can already run on Ubuntu desktop. I know other desktop/mobile platforms are also working towards the convergence goal, it will be interesting how it plays out. I can see Android desktop apps not being too far away, for instance.

5 years goes past pretty quick, if I think of desktop or web apps 5 years ago not that much has changed.

I have a lot of faith in browser engines continuing to make a great progress, and web as a platform has more developers and momentum than anything else so I expect to see a lot of interesting things coming out as web based SaaS software.

If I think of some of the more complex desktop apps I use (things like Photoshop, After Effects, 3DS Max, Logic Pro, Davinci Resolve) I don't think those will be replaced in 5 years by apps running solely on web technologies. I think something like Qt offers a better fit for these types of apps if cross-platform is a goal.

Having said that, apps of that complexity are a small fraction of what people actually use - as web closes in on the quality of user experience of native apps I think more and more traditional desktop and mobile apps will be built with web technologies.

And there will probably be some curve balls in terms of how people interact with computing devices like IoT devices and Oculus Rift/Magic Leap type wearables with completely new interfaces.

</comment><comment><USER20> Well, reading comments was interesting. A lot of "we need a faster horse" thinking, and, sadly, a lot of "we don't care about the users" thinking too. By "we don't care about the users" I mean thinking purely from the developers perspective, not from "make it harder for the database easier for the user" POV. And you can substitute database with developer. For those hoping for the rise of web, I'd suggest a few points to consider. The most important: what advantages does this kind of approach have compared to native — and to think about that form user's perspective. Run the same app everywhere? Ok, but typical user does not switch platforms that often on the same kind of device. Switching desktop/mobile is another matter, but there is an alternative to running the same everywhere, e.g. Apple's continuity.

Ease of updates: just go to the same URL and you get the version. Well ok, what if I don't like the new version? How do I keep the old one? And how big advantage is that (again, from users perspective) compared to app stores and auto updating, that is already there?

I am afraid that in five years from now we will see the same we saw five years ago: throwing in half-baked features into browsers to keep them "on-par" with native APIs and endless search for THE framework. The trouble is, that while native have those frameworks at foundation, web tech basically requires them to be bolted on…

</comment><comment><USER29> In 5 years you'll have to know C++ and emscripten as it will be the main way to develop frontend applications.

<comment><USER30> Said nobody ever.

</comment></comment><comment><USER31> What is happening now and will be even more prominent in the next 5 years is that people will be using web technologies like html, css and javascript to write one codebase that is transferable to any platform (browser or native).

Nowadays with node.js you can convert your web-app to an android, ios, mac, windows app, etc. You have access to system hardware, and from the users perspective it is no different than any native app, even though it is built with web technologies.

It is quite amazing, html, css and javascript standards are becoming a universal platform for developers. We are writing apps for html5 architecture vs specific processor architectures. The browser is a compile target and javascript is becoming like bytecode.

I see a future in which we develop multiple new ways of coding apps using web technologies, completely different than the way we do now. We will have various languages, methodologies to do it with but in the end it will all compile down to code a browser rendering engines can understand. And we can use this rendering engine to run the app outside the browser.

So basically I am saying we can code apps in various ways that compile down to web-technolgies and use this single codebase to port to any platform. And the user experience will be indistinguishable from native apps coded directly for the platform.

</comment><comment><USER32> Apps would have won as the browser still try to catch up with the richness of desktop environemnts.

Everyone will be back to native application development, with REST/socket protocols to communicate with micro services in distributed servers.

HTML will be used just as multimedia document format as a means of providing an interactive reading experience, while a group would be pushing for HTML 6 as the real thing.

<comment><USER20> Oh, how I'd like to see sanity going back to the web and identity crisis to be over. I am sick of that constant search for the holly grail of silver bullet framework. Guys, how about admitting that html, css and js are not really the best tools for the job of building apps?

</comment></comment><comment><USER33> It's an exciting future for web apps – I'm more interested to know who's going to take us there. It will require a significant collaboration between the browser makers and the operating systems – and while sometimes they are the same people, the major players have a conflict of interest.

When the iPhone launched without an app store or sdk, apple pushed for web apps. Yet [this article]([https://developer.apple.com/library/safari/referencelibrary/...](https://developer.apple.com/library/safari/referencelibrary/gettingstarted/gs_iphonewebapp/_index.html)) hasn't been updated in over five years. And Apple has very little incentive to do so now. The Chrome web app store is a promising concept, but I'm not convinced it has great traction.

My fear is that as web apps gain access to native app features, standardization will go out the window as each operating system (or maybe browser at that point) competes for market share.

</comment><comment><USER34> I hope we trend towards open, public APIs that make which interface you build or use just a personal choice that others don't have to live by.

One example is HN, they've recently released an API and when that is full- featured apps and alternative sites built on the API will be able to completely replace the HN website for anyone who want them.

<comment><USER25> It's a platonic ideal, but the internet runs on ads, and that ruins everything.

An interface you don't control is an interface you can't advertise on. The vast majority of players will never open their data in a manner that hurts their ability to sell sponsorship, and this problem is entrenched in the fabric of the internet.

HN is a very, very rare exception in that it never was and never will be dependent on ad funding.

<comment><USER19> What about licensing their API? Could that be a viable business model for both the website and the app creators?

</comment></comment></comment><comment><USER35> Javascript will no longer be the only viable language for working with the DOM in a browser. With technologies like asm, I think it is only a matter of time until we are freed of directly or semi-directly (coffeescript) coding Javascript in every project. If it isn't asm, I think this will happen one way or the other.

</comment><comment><USER9> I like the idea of a gradual merger of the abstractions we now call browser and operating system. I think that I first read about this idea years ago when ASUS floated the idea of having a ChromeOS-like thing in firmware, but I can't find the link.

The important point is that, like microwaves, for 99% of people (even devs), it will make no difference at all who makes the software running in the background. Sort of like BIOS. It will all look and act exactly the same: basically a browser. I already see this convergence happening in mobile, web, and desktop. There will be some other contentious thing to fill the HN threads, some new interface abstraction or maybe VR. Whatever abstracts the most away while working on the most number of devices seamlessly will become increasingly more interesting.

</comment><comment><USER36> Well, for Web Development, I hope it will have mature support for languages and APIs compiling to JavaScript. Emscripten is a nice demonstration on how given the right tools the web can be a great target for porting to. Today it's missing some support for C++ features and libraries but one day maybe we'll not only have the tools with full POSIX/UNIX APIs but Windows, Java and Android APIs too.

As for Web practices I hope everyone embraces responsive design as being served a separate ghetto version of a site with less features is lousy. I hope everyone stops making a app for their site as that's usually just as bad as the ghetto mobile site if not worse because perhaps the developers didn't have experience in that platform.

</comment><comment><USER37> Perhaps a move away from apps to widgets -- users will continue to be impatient with anything other than the fastest way of getting things done on a device. So rather than launching an app, reaching a home screen and then selecting an option from there, apps will provide direct links to specific actions that can be invoked from the OS. For (a simple minded) example: you don't launch the Twitter app to tweet, you invoke the 'tweet' action.

And possibly, the concept of API's might hit desktop environments and we might be able to string together such actions much like we do with UNIX piping, allowing for more automation (e.g. 'append this text to document x with time stamp', where the doc is rich text document)

<comment><USER38> Somehow I don't see Apple doing that

</comment></comment><comment><USER39> We will move to a cloud based model and all your data will be owned by the cloud providers. Google, Apple and Microsoft are already ensuring this.

From a Google filing in court about Gmail privacy:

>Indeed, "a person has no legitimate expectation of privacy in information he voluntarily turns over to third parties." Smith v. Maryland, 442 U.S. 735, 743-44 (1979).

> it's "inconceivable" that someone using a Gmail account would not be aware > that the information in their email would be known to Google.

Also referenced the scroogled ad campaign to support that users know and accept this behavior.

/facepalm

<comment><USER40> The fact that your data is stored on a cloud provider doesn't mean that that provider _owns_ your data. For example, from Google's TOS:

"You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours." [0].

The context of the quote from the court documents you referenced [1] is that Gmail inevitably needs to be able to process your emails in order to send them (and potentially filter out the spam). It is not, as you seem imply, about violating your privacy.

[0]: [http://www.google.com/intl/en/policies/terms/](http://www.google.com/intl/en/policies/terms/)

[1]: [https://www.scribd.com/doc/160041493/Google- Motion-061313](https://www.scribd.com/doc/160041493/Google-Motion-061313)

</comment></comment><comment><USER41> [http://blog.intercom.io/the-end-of-apps-as-we-know- them/](http://blog.intercom.io/the-end-of-apps-as-we-know-them/) \- This article about where mobile apps are going resonated with me. It says we're eventually moving away from a bank of homescreen icons to notification centers and all actions related to certain context are present in the notification itself (like, reply). Moreover certain products/services might not need to have their own app - piggybacking as child cards of others app notifications. Very fascinating read.

</comment><comment><USER42> Shared interfaces used by browsers and apps alike. JSON will rule the interface, JS will continue to dominate the client side but you'll never see it because it's something generated by your server side framework if the client is not 'native'. Browsers will be the step-up to downloading an APP or a plug-in to the browser.

Pendulum comes fully around, it's already happening in some arenas.

Would you like to download 'facebook' to enhance your browsing experience?

</comment><comment><USER43> The thing you watch in the living room will increasingly be connected to the internet, and be able to function interactively.

In the kitchen appliances will increasingly be connected to the internet and be able to download recipes.

The ingredients list your blender displays for Pesto will be transmitted in HTML. But I will write it in markdown.

Your crispy skinned pork roasting application will execute as JavaScript. I wrote it in JavaScript, I will think about writing it in Clojure next time.

</comment><comment><AUTHOR> I see web apps taking an even large slice of previously desktop apps. I believe Operating Systems will no longer matter as much (this is happening now) as they did in previous years. I would really like to see something other than JavaScript (etc) on the web.

Other than that I see the mobile app market exploding. More people will (if not already) be on mobile platforms than the standard computer. If there was a seamless way to merge mobile and web apps the possibilities are endless.

<comment><USER20> I am curious, which slice of previously desktop apps is already taken by web apps?

<comment><AUTHOR> Of course not completely taken but to name a few: email, word processor, calendar, music player, chat clients, and many more.

</comment></comment></comment><comment><USER44> We don't have the same pace of innovation happening on the big screen that we did in previous decades.

Desktop apps are the same except for upgrades to their UIs and engines. Web apps are the same except for an explosion of .js libraries - some production worthy - and a shift in popularity away from php.

Most of the innovation is on smartphones. Those in turn are most like the desktop, but with more interesting I/O - at least for a developer.

</comment><comment><USER45> I believe that web apps especially will see an Internet of Things (IoT) takeoff. Things like a web service to remotely control your house (lights heat TV etc) are prime and ready and wouldn't require that much work.

That may seem obvious for web apps; there's a wiki page for IoT. For desktop apps, I predict interfacing with mobile more. Making it seamless to go from one device to the next. We're almost there but not quite.

<comment><USER46> I think it will be less of a matter of you remote controlling your house, and more a matter of your house learning your habits. If remote control continues to be a matter of you reaching over to your phone, unlocking it and stating a request, people will continue to just get out of bed to turn the lights on.

If, however, the house knows that you set an alarm last night for 4:00, and it is designed to slowly bring the lights up to simulate a natural sunrise, then you'll wake up with the lights on already, which is far more useful. If it offers to start the shower and bring up the lights in the bathroom after it confirms you're out of bed, even better.

I think we overestimate the amount of control people really want over the mechanical and electrical systems in their living space. Most people just want the thermostat to keep them comfortable, whatever that means.

</comment></comment><comment><USER47> I see a reborn over the LAN and even PAN with apps talking between them, on a private network, without requiring internet access to provide services. IoT would certainly be a major driver for this, but innovation in network services and protocols is stagnated. The whole point is to bring services to the connected clients, and a bunch of those services does not require internet access, but better machinery.

</comment><comment><USER48> Chrome is going in this direction:

Packaged apps that have more and more hardware permission.

I think JS will be a compile target.

</comment><comment><USER49> Multiple concurrent screens (phone, tablet, desktop, living room) as viewports onto your cloud-resident stuff.

The cloud will move away from being largely passive storage, into hosting active applications/agents.

The underlying OS API will lose its grip, but the cloud framework(s) will take over the role of application platform(s).

</comment><comment><USER50> If rest of the world follows what apple is doing with Continuity, I would say that is where we are going.

</comment><comment><USER51> Most people think there is going to be a move to the cloud ITT. This requires ubiquitous internet. TimeWarner merger is going to ensure the opposite, people will have latent internet connections and will not have OS in the cloud. 15mbps is too weak for that to be a true option.

</comment><comment><USER52> Desktop apps are basically stuck where they were 10 years ago, and I don't see them advancing much in the next 10. Office, Photoshop, etc will still be getting upgrades every couple years. All the investment will be in what the new hot platform is.

</comment><comment><USER53> I think in the next 5 years the focus will be shifted from desktop and web apps to virtual reality (Oculus) and smart hardware apps (smart homes, wearables etc).

Even for web apps it is going to be more mobile oriented than actual standard web view

</comment><comment><USER54> Since running a complex desktop app in the server and serving it to browser based clients is now a production ready solution I imagine this approach will become a bit more popular. (ref. Adobe's creative cloud)

</comment><comment><USER55> I hope that we'll see web-development-like desktop platforms. There are certain classes of apps that are really simple to develop as a web site, but comparatively hard as a native app. I would like to see something like node- webkit with a broader range of native controls. On the opposite side, I would like to see desktop toolkits to include more web-server-like functionality to make desktop-web-dev easier.

in general, very much like the idea of Firefox OS, where you basically develop a web-app, and publish it as a native app. I would like to see this on the desktop as well.

Oh yeah, and a truly first class alternative to Javascript in the browser is _really_ overdue.

</comment><comment><USER56> I actually see more and more web software becoming lazy.

i.e. long, single page applications where content is mostly displayed either in cards or in a feed format.

</comment><comment><USER57> There won't be a difference going enough in the future, but 5 years isn't enough. Native apps will get all the benefits of browser apps and vice versa.

</comment><comment><USER58> Internet surfing is my hubby. Symbianize.com is my favorite site that gives you access to many softwares that traditionally would be desktop only.

</comment><comment><USER59> I see them developing side by side. Native applications are here to stay and the browser will become more and more of a versatile VM.

</comment><comment><USER60> Desktop software is desktop because of mouse. Touch software replaces mouse with hand gestures on screen or panel. But web apps still trying to be 1990 desktop replacement. Soon biometric feedback makes this painfully obvious. Security and compatibility is key. But Apple and Microsoft refuse to agree on anything except basic web standards. Third player needed for anything to change.

</comment><comment><USER61> I can't see them anymore. Five years is a long time.

</comment><comment><USER62> I hope we ditch JS from web standards.

</comment><comment><USER63> Desktop software dead. Software exists only on the internet. Browsers evolve into application runners.

Thin fucking clients.

<comment><USER64> Commercial CNC machines and other motion control applications will _never_ run off of web-based software. Not to say it isn't possible under the right conditions, but those conditions can't be ensured. There will always exist applications that require low response times that the internet cannot dependably deliver.

High end CAD and CAM software also falls under this umbrella. There is simply too much computation/rendering occuring.</comment></comment>


The Chevy Bolt is GM's all-electric masterpiece - <AUTHOR> http://www.businessinsider.com/2017-chevy-bolt-review-photos-2017-3 <comment><USER2> This car is great. But for $7,000 I can take a risk on a Nissan Leaf and put $30,000 back in the bank.

And for $2,000 more you can just get a Model S [1]

[1] [https://sfbay.craigslist.org/pen/cto/6029938589.html](https://sfbay.craigslist.org/pen/cto/6029938589.html)

<comment><USER3> ... with 71,000 miles.</comment></comment>


Don't put BASIC code in your emails - <AUTHOR> http://pastebin.com/JLRJxm4g

<comment><USER2> > 10 Subject == getConfig(Email[Subject])

This is a particularly funny bug to write in pseudo-BASIC; considering that in BASIC a single '=' is used to test for equality, as well as for assignment.

I can see why they need all that process.

</comment><comment><USER3> 10 GOTO Subject? For Pete's sake!

That's the problem with this whole "structured programming" fad: nobody knows how to write honest, plain old spaghetti-code anymore.

As for me, I enjoy throwing a goto or two into my Obj-C and Java code every once and awhile. It's perfectly legit.

<comment><USER4> The world of programming started to fall apart as soon as lowercase was allowed in code.

<comment><USER5> Honest question. Is case (in)?sensitivity something people actually care about?

<comment><USER3> Get a load of this kid.

<comment><USER5> I guess that was a stupid question. Here comes the thought_alarm... ;)

</comment></comment></comment></comment></comment><comment><USER6> sounds like a healthy startup company to me. I loved the insider jokes that got passed around at the last good startup I worked at. We had a bugzilla bug passed around for 4 years and several hundred people before the company got bought out and went to hell. It was a good run though.

</comment><comment><USER7> So is structured development really better than off-the-cuff development? In this case it sure looks like a structured environment would have caught the bug in the original code but it also means 10 times more people getting their fingers in the pie.

</comment><comment><USER8> Before we all agree that BASIC is indeed dead, I have a friend that recently reached out to me for some help writing an AppleSoft BASIC app for some CS course. Never figured out why someone is still teaching it...

</comment><comment><USER9> The real question is what self-respecting programmer would instinctively reach for BASIC as the language to write a joke in? Methinks this says more about the jokester than he wanted to say...

<comment><USER10> Nostalgia? It's a language that introduced many of us to programming.

Edit: [https://plus.google.com/108914556664474359662/posts/K1xhEEtk...](https://plus.google.com/108914556664474359662/posts/K1xhEEtkoN6)

<comment><USER11> Vouch. I remember spending the entirety of my math class writing games on my TI-83+. I still hate my instructor for wiping my memory when she thought I was _playing_ them and not _writing_ them.

<comment><USER12> I remember the day I discovered an assembly program that mimicked a memory wipe, but could be restored with a hotkey combination. I was so damn smug after that.

</comment></comment></comment></comment><comment><USER13> Heh, looks like it's a Microsoft email thread -- the Ship-It reference suggests so.

</comment><comment><USER14> Thinking the joke could be much more elegantly written in Perl, sed, or LISP

<comment><USER15>
      (apply #'max (mapcar #'age-of (list-all-recipients)))
         ==> 21</comment></comment>


Wittgenstein for programmers - <AUTHOR> http://www.hxa.name/notes/note-hxa7241-20110219T1113Z.html <comment><USER2> It's funny because aside from denouncing the Tractatus as containing fundamental errors, Wittgenstein in following up with Philosophical Investigations seems to capture language (and, in the extended sense, programming languages) more accurately as a tool. Rather than being a vehicle for making true-false propositions about reality (like a picture), different facets of language are useful in different ways, just like we have a hammer, nails, glue, measuring stick. Just like the world of programs.

Thus the Tractatus framework is somewhat forced and a bit misleading, both in terms of Wittgenstein's own thinking and goodness of fit of the metaphor.

<comment><USER3> No, the Tractatus could still be applicable to computer programming. The problem with Wittgenstein's earlier work is that his idea of language was that it modelled reality. However, many computer programs really are trying to model something correctly, or at least that's what the Java and UML books tell us. ;) So the Tractatus could apply.

But the latter Wittgenstein is lurking in most real-world programs -- what they do isn't anything about describing a ideal model, it's just... what they do.

Anyway, I doubt any of this will help anyone write or understand computing better, but it's fun to think about.

</comment></comment><comment><USER4> This seems to set up some interesting parallels to the Tractatus, but I don't think it does so in a way that improves our understanding of software engineering. I'm tempted to put it in the "not even wrong" category, but I'm worried that may be too harsh, and I may need to go back and think on it some more.

Incidentally, computer-types may be interested to know that Alan Turing sat in on some of Wittgenstein's lectures on the foundations of mathematics, and they didn't quite see eye-to-eye.

[http://www.amazon.com/Wittgensteins-Lectures-Foundations- Mat...](http://www.amazon.com/Wittgensteins-Lectures-Foundations-Mathematics- Cambridge/dp/0226904261)

Edit: excerpt here: <http://www.turing.org.uk/philosophy/ex4.html>

</comment><comment><USER5> The idea of "programs as propositions" espoused here is in apparent conflict with the more widely known Curry-Howard correspondence [1], which states that programs can be interpretted as proofs and _types_ are propositions.

[1] [https://secure.wikimedia.org/wikipedia/en/wiki/Curry- Howard_...](https://secure.wikimedia.org/wikipedia/en/wiki/Curry- Howard_correspondence)

<comment><USER6> I'm not familiar with Wittgenstein (it's on my list), but I wonder if the difference is in the system of logic followed (intuitionist vs classical).

<comment><USER7> Unlikely, intuionist and classical logic are not fundamentally different. The only difference is that the law of excluded middle (A or (not A)) is an axiom (i.e. assumed to be true) in classical logic.</comment></comment></comment>


We Have Pushed Physics Too Far - <AUTHOR> http://cosmos.nautil.us/short/90/we-have-pushed-physics-too-far <comment><USER2> When I scroll down on that site, it fills my browser's "back" button with dozens of meaningless copies of itself.

<comment><USER3> It doesn't even seem to be necessary to scroll. Just sitting on the page seems to do it. Each time I check history there are more copies. I'm pretty sure I've been to that site before without that happening, so for now I'm going to assume it is just a bug in their JavaScript.

</comment></comment><comment><USER4> I see Nautil.us is joining the tribe of sensationalist titles. When did this become the norm?

<comment><USER5> when they needed to get viewership instead of subscriptions. People don't want to pay for news, magaziness, etc.</comment></comment>


The Light Phone 2 - <AUTHOR> https://www.theverge.com/circuitbreaker/2018/3/1/17066494/light-phone-2-ultra-minimalist-cellphone-indiegogo-crowdfunding <comment><USER2> I like the wider and wider usage of eink displays, I think it is an underestimated technology which solves the major energy drain by most current devices: The background lighting. Combined with low power processors we get the mobile battery life we were used from the 90s.

</comment><comment><USER3> 1\. Buy an iPhone; 2\. Tell a friend or your significant other to turn on the restrictions features without telling you the passcode. :P

</comment><comment><USER4> That screen looks amazing!</comment>


Google wants to hire the creator of 'Killed By Google' - <AUTHOR> https://9to5google.com/2020/04/14/google-hire-creator-of-killed-by-google/ <comment><USER2> No, they don't want to hire this guy.

This is recruiter spam that nearly everyone gets if you have the word "software engineer" in your profile somewhere.

</comment><comment><USER3> "Since your net worth is now tied to your RSUs, please show some ownership and delete your domain. Oh wait, you visited it while at work, so now it is considered work property and you mus hand over control of the DNS" \- a fictional account of corporate conspiracy</comment>


Getting Started with WordPress Static Site Generators - <AUTHOR> https://snipcart.com/blog/wordpress-static-site-generator <comment><AUTHOR> Covers the exciting growing trend of WordPress and Jamstack and how they can actually go together.</comment>


HN RFC: critique/break v1 of my app, Supermailer (a simple mailing list service) - <AUTHOR> http://supermailer.pearachute.com

<comment><USER2> You should provide an alternative to the "reply to confirm" over http. Just a link with the same secret. I find it easier to click those than to reply via mail, since I'm back at the originating application after I've clicked the link.

Think I found a bug. After I received the "All set!" email I got this message when trying to create a list: "Please reply to the confirmation email we sent you. Only verified email accounts can create a list. "

So, I'm basically unable to test the full application. But I loved what I've seen so far. More people should use minimalistic interfaces like this for their applications.

<comment><AUTHOR> I just backed out some changes, which should take care of that, what an embarassing bug!

Sending a link in an email is definitely in my tracker as a feature to be added. Thanks for checking it out.

</comment></comment><comment><USER3> You need to explain on the front page why I'd want to signup. List some features, give some info. What does it do? What makes it great? Why should I bother?

<comment><AUTHOR> Thanks for the feedback, that helps me gather up Qs for a FAQ.</comment></comment>


User Motivation Determines the Best Color Scheme for Your Website - <AUTHOR> http://kaikkonendesign.fi/user-motivation-determines-the-best-color-scheme-for-your-website/

<comment><USER2> I don't agree with Hedonism being the driving force behind dark websites. I prefer dark(and spend all day coding with a dark background) because it's easier on my eyes... The idea behind skeuomorphism in webpages mimicking paper has proven itself when the print industry attempted to carry their print practices over to the web and failed. The internet is still very young; I think what we will find over time as more and more people spend more and more time on computers is a departure from paperesque websites to a more functional design that is dark and physiologically friendly(easy on your eyes).

Interestingly enough, the website in the link looks awesome using the Hacker Vision Chrome extension I use which is designed to do just that - it applies a dark theme to all websites so the bright white backgrounds don't destroy your eyes.

Download Hacker Vision at: [https://chrome.google.com/webstore/detail/hacker- vision/fomm...](https://chrome.google.com/webstore/detail/hacker- vision/fommidcneendjonelhhhkmoekeicedej)

<comment><USER3> This seems very unnatural. Step outside on a sunny day and tell me we're not built (as a species) to function optimally in bright light.

I'd even go so far as to say that several hundred thousand years of evolution would back me up. Otherwise, why can't we see perfectly in the dark?

EDIT: typo.

<comment><USER2> We aren't equipped to see perfectly in light or dark, we have a range. Everyday is sunny here and people wear sunglasses. I'm not disagreeing with you though - I think the difference is that monitors are backlit and things in nature that create light you tend to not look directly at for 8 hours a day.

</comment></comment></comment><comment><USER4> The fight against "default" white seems analogous to Ian Storm Taylor's recommendation to never use black (<http://ianstormtaylor.com/design-tip- never-use-black/>). I prefer off white (e.g., #f9fafc) because of the same reason I like text color set at #333 — it looks softer, but still almost imperceptibly different from #fff/#000's traditional "paper and ink" aesthetic.

<http://www.colorcodehex.com/f9fafc/>

<http://www.colorcodehex.com/333333/>

<comment><USER5> I believe in using a black background for talk slides.

Example: [http://new.livestream.com/gigaom/gigaomroadmap/videos/579403...](http://new.livestream.com/gigaom/gigaomroadmap/videos/5794034)

I would prefer dark gray from an aesthetic perspective. But the reason I choose black is simple:

Often, the LCD projector is not pointed straight at the backdrop or maximized correctly. If your slide background is not black, there is a perceptible margin, and your slide area is shaped like a trapezoid, not a rectangle. Using a black slide background minimizes this margin, and makes it look like your slides correctly fill the backdrop.

Just my two cents. I'm curious if people feel strongly against this approach.

<comment><USER6> White on black is very hard to see in a brightly lit room. Many programming talks like that color scheme and it just doesn't work with crappy projectors.

</comment></comment></comment><comment><USER7> I force all sites to display as something like #E0 on #28. I find it far easier on my eyes. I use a Firefox extension that lets me switch back to the original scheme with a shortcut for the few sites that don't function when you override the colours.

</comment><comment><USER8> > Why the Web is White

"And what happens if the Twitter mob finds out..."

</comment><comment><USER9> Author: Search for "pleasuraigh".

<comment><USER10> The article was pretty, but too many typos in it to count...

EDIT to --> too

<comment><USER11> You mean 'too many' and not 'to many', right?

<comment><USER10> Of course..

</comment></comment></comment></comment><comment><USER12> I wonder if these color schemes are chosen primarily because it's what's traditional and expected; we don't like to surprise our users/customers as it may induce negative feelings, including a lack of trust. For example, we expect a fashion website to look different to a web app, and when something is discordant with our preconceived notions we trust it less. I think that typically designers intuitively go for a less-surprising aesthetic rather than an atypical one whose aesthetic induces a degree of trust-eroding cognitive dissonance.

The one utilitarian site I can think of that breaks the author's pattern is Wufoo; bold colors, utilitarian purpose. They seem to be quite successful too. Having said that, a single counterexample doesn't diminish the validity of the author's central thesis, but it might just be one notch in the larger key.

<comment><AUTHOR> I don't disagree that designers choose a less threatening aesthetics that incorporates familiarity. Pandering to the lowest common denominator eventually leads to the most familiar of features - GOOG is just a box and two buttons, for example.

I would also argue that the Formerly-Known-As-MetroUI pattern is also rather utilitarian. It was designed to have a low information density, but highly relevant information - that is to say, show less, but show higher quality information.

Too bad people have constantly misused those great ideas in patterns tho

</comment></comment><comment><USER13> Because of the historical accident of paper being white and ink being dark. The human eye is somewhat better at reading light-on-dark, but most people aren't used to it.

<comment><USER14> But there's also the historical accident of early computers primarily using light-on-dark displays (I always found amber-on-black mode less harsh on the eyes than green-on-black, personally—but just don't get me started on white- on-blue, bah!), which we then moved away from in favor of dark on light.

(If I had to guess the reason for _that_ historical accident, I'd think it had to do with "white" not being a particularly uniform color on a lot of older CRTs, but one with varying hue and intensity in different regions.)

I find light on dark hard to read, even in low light. If I'm reading on my phone at night and use light-on-dark, the text looks blurrier to me than if I change it to dark-on-light (where "light" is a shade of gray that isn't harsh in a dark room).

(I wonder if dark ink on white paper took off over white ink/paint/whatever on dark paper because most people found it more readable. Anyone know about the history of paper/inks/paints?)

<comment><USER15> >If I had to guess the reason for that historical accident, I'd think it had to do with "white" not being a particularly uniform color on a lot of older CRTs, but one with varying hue and intensity in different regions.

also, the earlier monitors flickered more than later ones, and the flicker was more troublesome when the default/background color was light.

</comment></comment></comment><comment><USER16> One must take in consideration the environment of their users.

Try to look at a white screen while being in dark place. It hurts.

<comment><USER17> Use redshift or flu.x or so.

<comment><USER18> I use redshift religiously.

Hint: install it during the day. Not having it will hurt after a few days.

</comment></comment></comment><comment> cool-RR It makes me incredibly sad that people are willing to stare straight ahead at a fucking lightbulb (a.k.a. sites with a white background) and destroy their vision.

<comment><USER10> There's a lot to discuss here. I personally cannot read through light-on-dark digital designs. After a few lines everything blurs. With dark-on-light on the opposite I can read for hours.

Most probably is due to a non-optimal screen both at home and work-place, but I suffer from the same issue even on 2010 iMacs.

But the most pleasant scheme for me (I mean, my eyes) is light-gray-on-dark- gray.

<comment><AUTHOR> It's the contrast between the text/content and the background that affects your comfort though. There was an article about how you should never use black for your text on a white bg[0]. I think the points there are rather salient.

In fact the W3C has a good calculator for colour contrast [1], which I think is a good guide for calculating colour contrast when designing sites

[0]<http://ianstormtaylor.com/design-tip-never-use-black/> [1]<http://www.w3.org/TR/WCAG20/#contrast-ratiodef>

<comment><USER19> I think there are no points in [0] what so ever to support the claim than one should not use black (#000). The author does not argue at all. All he does is present a photo he has taken which does not have black pixels. What the hell is that supposed to prove?

<comment><USER10> I should redirect you to the interesting discussion happened on Ian's article here on HN.

About eye stress.. that's another story. Could anyone here point us to a __scientific __paper out there?

</comment></comment></comment></comment></comment><comment><USER20> Utter bullshit. The original background color of websites was #c0c0c0, the same default color grey used in desktop apps. It was a big to-do, switching that default. The reason most sites are blue is because the human eye is better able to distinguish shades of blue. Also, a significant % of people are red/green colorblind.

<comment><USER21> > The reason most sites are blue is because the human eye is better able to > distinguish shades of blue.

Huh? It's shades of yellow/green that we are best able to distinguish. We're not good at blue.

<comment><USER22> Yup. Mind, color is _really_ complicated. The math to calculate color spaces is completely non-obvious, the eye's reactions to colors is subtle, and the brain seems to interpret colors in interesting ways. (I remember at work, we needed to figure out why a thing was getting _more_ red as we shifted it into the blue spectrum... turns out that's why they call it ultraviolet.)

I'll refer to a cool demonstration of this in action: <http://news.ycombinator.com/item?id=1891753>

It's not scientific, but it's certainly telling.

TL;DR: Green is the color we see well.</comment></comment></comment>


Where Glaciers Melt Away, Switzerland Sees Opportunity - <AUTHOR> https://www.nytimes.com/interactive/2019/02/13/climate/switzerland-glaciers-climate-change.html <comment><USER2> The glacier melting trend is actually incredibly fast.

Before I moved to Switzerland at the start of this decade, I visited the Rhone glacier. It's a stunning drive, well worth the trip. When I got there, it looked like a frozen waterfall, coming over the edge of the cliff where the tourist vantage point is.

It's only open in the summer, so I'd drive down there each summer.

Each summer, it was like going to a new glacier. It retreated by a lot each time. You didn't need photos to notice that it was a good 10-20m shorter each time. The last time I went a few years ago the rocks on the edge were completely exposed and you had to walk a fair bit to where the ice was thick enough to carve a tunnel into.

If you looked in the tourist shops and the old hotel, you could see paintings of the glacier in the 1800s. Back then it filled up the whole valley. Nowaways you can see young trees there.

<comment><USER3> If you are ever in the Engadin valley, I can recommend the Morteratsch Glacier trail. There are signs along the trail to indicate the historic positions of the glacier. It's incredibly impressive how much the glacier retreated over the last few decades. It also really drives the point home that climate change isn't a new phenomenon, we've been at it for a couple centuries now. But it picked up a lot of speed recently.

<comment><USER4> I read that the retreat of some glaciers in the Alps uncovered ancient Roman artefacts like coins. So it is probably not the first time they retreat either.

<comment><USER5> Do you believe inside the next 2000 years they will recover? The underlying premise is not that climate has not changed before. The premise is that there is no strong belief the cyclic nature of glacial retreat will be seen in any sensible timeframe (tens of thousands of years)

<comment><USER6> There are hypotheses that the last mini ice age was caused by slaughtering native am populations in the 1500s, causing their crops to grow back.

I'm not going to suggest a slaughter obviously, but an extremely strong economic recession could bring us back to pre-1990 carbon levels (when they were balanced, as per IPCC).

<comment><USER7> You're mixing up stocks and flows. Emissions are a flow. Co2 level is a stock. A recession will reduce the flow, but the stock will still increase.

The hypothesized decrease of co2 in the 1500s from native american death was a decrease in the stock. Farmlands returned to wild states and sequestered carbon.

</comment></comment></comment></comment></comment></comment><comment><USER8> A fact missing in this article is that dams in Switzerland are used for energy storage nowadays. It used to be the case that during lunchtime hydro produced most of the peak energy. Atomic power was used to pump the water into the dams during the night. Nowadays solar and wind, mostly from northern Germany, provide so much energy througout the day that it is more efficient to pump water into dams during lunchtime. It is unclear if these big dams can be run profitably.

More context: [https://www.nzz.ch/schweiz/aktuelle- themen/pumpspeicherwerk-...](https://www.nzz.ch/schweiz/aktuelle- themen/pumpspeicherwerk-linth-limmern-die-batterie-im-berg-ld.114664) (German)

</comment><comment><USER9> Thankfully Switzerland has the resources to manage this phenomenon - one of the more hair raising natural disasters are glacial lake outbursts, capable of unleashing a wall of water down mountain valleys: [https://en.wikipedia.org/wiki/Glacial_lake_outburst_flood](https://en.wikipedia.org/wiki/Glacial_lake_outburst_flood)

You really don't want to be a poor Nepalese villager living in one of these valleys when that happens.

</comment><comment><USER10> The site in question is part of the UNESCO World Heritage site 'Swiss Alps Jungfrau-Aletsch'; its description by UNESCO [1] mentions, in part:

" _It features a wide diversity of ecosystems, including successional stages due particularly to the retreat of glaciers resulting from climate change. The site is of outstanding universal value both for its beauty and for the wealth of information it contains about the formation of mountains and glaciers, as well as ongoing climate change._ " [1]

Not entirely sure how a new dam would be compatible with its heritage designation, but it would certainly continue to illustrate ongoing climate change.

[1] UNESCO World Heritage List, 'Swiss Alps Jungfrau-Aletsch' [https://whc.unesco.org/en/list/1037/](https://whc.unesco.org/en/list/1037/)

</comment><comment><USER11> I don't get it. From the point of view of electricity generation and freshwater flow, what is the difference between a stable glacier and no glacier at all? I am probably missing something, because assuming constant rainfall, a stable glacier's contribution should be neutral.

Shouldn't we say that, from the point of view of energy generation and freshwater flow, climate change has been a net benefit so far, which we'll stop enjoying in the foreseeable future?

<comment><USER12> Rain/snowfall is limited to a small(ish) number of days, while meltwater is on a predictable 12-month cycle. With rain that just flows down the mountain, you get a few days of far too much water, and the rest is dry.

The glacier (and snow) average out flow over time. It acts as a natural holding pool.

<comment><USER11> I thought about that, but while it's true that a glacier acts as a buffer, I guess that rain at those altitudes always falls as snow- for the majority of the year but probably in the summer as well- then proceeds to melt away during the summer. So the buffer effect shouldn't be entirely gone.

</comment></comment></comment><comment><USER13> I loved the experience of reading this article. The flow through the images, animations, and text all controlled without thinking only using one input- device was executed perfectly. There was a strong connection between the text and the image media where one would give way to the other but at the same time supported each other throughout without taking control away from the user.

<comment><USER14> Fascinating

[https://screenshotscdn.firefoxusercontent.com/images/1107934...](https://screenshotscdn.firefoxusercontent.com/images/11079349-2d78-4103-876e-cde093151669.png)

</comment></comment><comment><USER15> Yes while some will temporarily benefit from global warming, the vast majority of humanity will suffer. We need articles about THAT story. Given that we are now in a mass extinction event (60% of animals gone in last 30 years, looking like 80% of bugs) people need to start doing some serious research into why, particularly how global warming is involved. It's likely very much involved. The recent research about the 98% drop in bugs in the Puerto Rican rainforest found that global warming seems to be the main cause, with extremely hot days becoming very frequent.

Edit: Nobody likes the gloom and doom stuff I guess. Nothing to see here, everything is fine.

<comment><USER16> > Yes while some will temporarily benefit from global warming, the vast > majority of humanity will suffer. We need articles about THAT story...Nobody > likes the gloom and doom stuff

That's exactly the balance I see in climate change reporting. It's almost all doom and gloom. Articles like this one, which shows both positives and negatives, are an oddity.

<comment><USER17> There are positives if you live on an ice-clad mountain, or a country that's mostly ice-clad mountains.

There aren't many if you live in a river delta, or a country that's mostly river-delta.

8.5m people live in Switzerland, 165m in Bangladesh, to pick two examples.

<comment><USER18> I'd say the benefits are dubious even for countries with mountains. You don't own your country. If people in Bangladesh are displaced because of global warming, they have a right to move into neighboring places in India, Nepal, Bhutan, and Tibet. I think the same is true for the Arabian peninsula and Central Europe. What are you going to do? Shoot and kill refugees?

</comment></comment></comment></comment><comment><USER19> It wasn't mentioned in the article, but high altitude lakes are perfect for pumped hydro and with enough excess capacity in the system they should be able to mitigate the issue of declining meltwater by pumping water back to the top.

<comment><USER20> But wouldn't they expend more energy moving the water up the mountain than what it will generate? Second law of thermodynamics and all, I don't see how you can give water the same potential energy it had before it flowed through the turbines.

<comment><USER21> Of course, but pumped storage is about energy storage, not generation. It allows energy to be stored when generation is cheap, and then released at peak hours. It's remarkably efficient compared to most other storage systems.

<comment><USER22> Are there numbers for that? I'm thinking of comparing that to a flywheel or even just different electrical storage options.

<comment><USER23> Flywheels, superconductor storage or supercapacitors are somewhat more efficient [1], but they are an order of magnitude more expensive per unit of energy they can store. (Thousands of dollars per kWh capacity, rather than $200-$300.)

The real competitor is Li-Ion batteries which now cost about the same as pumped storage, and have similar cycle efficiency. Problem is the capacity decline after a few hundred cycles, which is unfortunate if you want to build infrastructure that is low-maintenance and survives decades.

If you are interested in the area, this blog post gives some thoughts to implications [2] though it is a bit outdated by now.

[1] [https://www.researchgate.net/figure/Comparison-of-various- EE...](https://www.researchgate.net/figure/Comparison-of-various-EES- technologies-in-cycle-efficiencies-4_fig5_283831474) [2] [https://dothemath.ucsd.edu/2011/08/nation-sized- battery/](https://dothemath.ucsd.edu/2011/08/nation-sized-battery/)

</comment></comment></comment></comment></comment><comment><USER24> Ugh - more retreating from nuclear caused by ignorant fear mongering :(

<comment><USER25> Why would someone prefer a nuclear plant over a hydro plant?

<comment><USER3> Hydro plants (specifically, dams) can be very disruptive to the local environment. You're flooding entire valleys.

They can also pose a substantial danger in the case of failure, see e.g. [https://en.wikipedia.org/wiki/Vajont_Dam](https://en.wikipedia.org/wiki/Vajont_Dam) (~2000 casualties, vs Fukushima Daiichi's estimated death toll of ~500).

(I'm a big fan of hydro power, just saying it also has its draw backs)

<comment><USER11> While the death toll of nuclear accidents is relatively low, their economic cost seems to be staggering. The Japanese authorities enforced a 30km exclusion zone around Fukushima; if an accident of similar size had happened to the Beznau nuclear plant, the entire city of Zürich could have fallen inside the exclusion zone. Just think of the real estate value vaporized. Even if it's one event in a thousand years, I'm not sure it's worth the risk.

<comment><USER3> Fun fact, there were serious plans in the 1950ies to build a nuclear power plant right _in_ Zurich, primarily as district heating for ETH Zurich.

[https://www.research- collection.ethz.ch/bitstream/handle/20....](https://www.research- collection.ethz.ch/bitstream/handle/20.500.11850/88080/eth-30387-01.pdf) (page 83, German)

</comment></comment></comment></comment></comment><comment><USER26> I hate this new trend where existing text you are reading is faded out and replaced with an ad. So you have to scroll up to read what you were reading, then hit the ad again.... only to scroll past the ad and realize they don't show the previous paragraph... to hit the ad again.

I'm sure it's great for ad impressions, but the hate it generates surely outweighs any possible benefit to the advertiser.

No wonder revenue per ad is dropping.

<comment><USER27> I'm surprised every time I read about people's disappointment about ads, especially on HN. Not because I have problems with their disappointment, but because it genuinely surprises me to discover people that don't use ad blockers, even more on HN.

What's the reason for this? What moves so many people to opt against using an ad blocker? It surely can't be lack of awareness that such tools exist, not for an audience like that of HN.

<comment><USER12> Awareness that free content won't exist in a world where everyone uses ad blocker?

I sometimes find ads annoying when, fir example, they change the layout. But I leave it in by default.

What I don't understand is what you think you have to gain from advertising ad blockers? If people subsidize your entertainment, shouldn't you be happy?

<comment><USER28> As far as I'm concerned, I'm not using an ad blocker, I'm using a _third party tracker_ blocker. A reasonable number of ads, even in the middle of an article, are fine with me (well, as long as they don't pop up, obscure content, move or animate, or make sound). The name of the former extension "RequestPolicy" neatly sums up what I want: to be able to tell my browser to contact only hosts that I want it to contact. Also, malware blocker and CPU cycle saver.

</comment></comment></comment></comment><comment><USER29> This presentation is openly contemptuous of its readers. No thanks.</comment>


The Internet Killed the Rock Star and Why That's Okay - <AUTHOR> https://medium.com/@kolemcrae/the-internet-killed-the-rock-star-and-why-that-s-okay-3a522eb07154

<comment><USER2> The internet didn't kill the "rock star," but it did provide niche "musicians" (i.e. service providers) with a platform to serve niche audiences by drastically reducing cost of entry. Anyone with a camera phone can start up a YouTube channel and become a content creator with almost no resources, but there are still "rock stars" like PewDiePie making millions of dollars with millions of fans.</comment>


Kubernetes 1.16 - <AUTHOR> https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement/ <comment><USER2> I wish their tech writers would give us more English and less jargon. I pondered these release notes and the documentation earlier today and I still can't puzzle out why "custom resource" is initialized as "CRD".

And the rest of this gibberish is just meaningless.

"""A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind."""

OK, almost completely free of meaning ... then later:

"""A declarative API allows you to declare or specify the desired state of your resource and tries to keep the current state of Kubernetes objects in sync with the desired state."""

But wait, I thought the resource _was_ an API endpoint? The API allows me to declare the desired state of my API?

I know K8s is not Borg and I know a lot of xooglers hate Borg but at least the Borg documentation was concise and made sense.

<comment><USER3> It's not gibberish, though.

A resource _has_ an endpoint, i.e. a URL that represents its configuration and state. But a resource and its endpoint can be thought of as the same thing, in that the endpoint is the resource's canonical URI. Think REST/HATEOAS.

A resource is any object that Kubernetes can track. They include objects like services, pods, nodes, ingresses and so on. Together resources form an API.

A CRD is a Custom Resource Definition. It defines the schema and API of a custom resource (as opposed to a built-in one like "service" or "pod").

A resource is pure declarative data -- configuration and state commingled in one JSON document -- but can have behaviour associated with it.

(Confusingly, Kubernetes also uses the word "resource" to refer to compute resources like CPU and RAM. For that reason, you'll often see "object" used instead.)

<comment><USER4> "But a resource and its endpoint can be thought of as the same thing, in that the endpoint is the resource's canonical URI."

After reading your description, "a resource is an endpoint" still seems wrong. Perhaps just lazy, but laziness in technical docs gets confusing fast.

<comment><USER5> It's not laziness at all. It's the project's Ubiquitous Language, which helps refer to concepts objectively and free from ambiguities. You're complaining because you are not familiar with Kubernetes, and thus you are not the target audience. Do keep in mind you're reading the release notes of a minor release.

<comment><USER2> With respect I disagree and my objection is that this verbiage is ambiguous and imprecise, the opposite of a ubiquitous domain language. Why does the "declarative API" allow one to "declare or specify"? Which is it? Is there meaning in the clause "or specify", or is it a superfluous verbal tic? If the API is declarative why is it called a Definition? Declaration and definition are well-used terms of art in our industry but they are not synonymous. And what about "tries to keep them in sync"? Tried by what means? Are they eventually synchronized or not?

</comment></comment></comment></comment></comment><comment><USER6> We're moving away from Kubernetes because managing even a simple implementation is a full-time job. Obviously Kubernetes is meant for enterprises, but I've seen seed round/series A startups with a small engineering team using it.

We were at a crossroad. Either we hire an SRE that has extensive kubernetes experience for $130K/year or we move to a managed platform until we actually need those capabilities.

We're happy with the move and the pressure relief is tremendous. Now we can focus on features and not whether or not deploying is using ENV vars from our local machines and causing the system to crash.

<comment><USER7> Why not just used managed Kubernetes? Every cloud vendor has it, even Tier 2 operators like DigitalOcean.

Running Kubernetes is vastly different for using it to run your apps. You really shouldn't do the former unless you have to be on-Prem or have some other need.

<comment><USER8> There's a ton at play here.

"Managed Kubernetes" really runs the spectrum between "one step above just installing it yourself on a bunch of VMs" and "I spend 1% of my time managing anything below the product." Each cloud provider exists somewhere different on this spectrum, with none of them being in quite the same location, and some of them have _multiple different products_ which exist at different points.

For example: AWS is among the most bare-bones. EKS is just a managed control plane; coming from GKE, you might click "create an cluster" then be very confused how there are no options for, say, instance size, or how many... because you have to do that all yourself. There are tools like eksctl or Rancher which can help with this, but ultimately, you're managing those instances. You're doing capacity planning (you think kube would be a great pick to integrate with spot fleets because of its ability to schedule and move workloads to a new instance when one goes down? have fun setting it up, hope you like ops work.). You're doing auto-scaling (and that ASG? its not going to know about your pod resource requests, so you either need some very smart manual coordination between the two, or you need to set up cluster- autoscaler). You're setting up cluster metrics (definitely need metrics- server. not heapster, that was last year, metrics-server is this year. but how to visualize? do i host grafana in the cluster? then i need to worry about authn. cloudwatch really isn't made for these kinds of things... maybe I'll just give datadog a few thousand bucks.) Crap, 1.16 is out already? They only support 9 months of releases with security updates?! I feel like I just upgraded my nodes! Oh well, time to lose a day replicating this update across all of my environments.

I'd go on, but you get the point. There is nothing "managed" about EKS.

DigitalOcean is pretty similar to this (it does provision instances, but the tooling beyond that is barebones). Google Cloud/GKE is "more managed" in a few sense; the cloud dashboard provides some great management capabilities out-of- the-box, such that you may not need to reach for something like Datadog, and the autoscaler works really well without a lot of tinkering. There are still underlying instances, so you're worrying about ingress protection, OS hardening, OS upgrades, etc... but its not as bad as AWS. Not by a long shot.

The holy grail (for some companies) is really something like Azure AKS + Azure Container Instances. No instances to manage. Click a button for a kubernetes cluster. Schedule workloads. Get functional metrics, logging, tracing, dashboards out of the box. Don't worry about OS upgrades, hardening, autoscaling, upgrading the cluster, etc; we'll do it all for you, or at least make it one click to configure. That's the ideal situation. I haven't used AKS/ACI so I can't comment on whether Azure gets us there, but the idea is sound; even if its more expensive.

This sounds like an anti-Kube post, right? Wrong (its a Tide ad). The beautiful thing about Kubernetes is that _it can span this spectrum_. The same exact API surface can scale from a fully-managed abstract platform where you just say "take this git repo and run it" (see: Gitlab Auto-DevOps), all the way to powering millions of workloads across dozens of federated clusters at Fortune 500 companies.

But, to the OPs point: We're close to solving that right end of the spectrum, and a lot further away from the left end. We're getting there, but we're not there yet. There isn't enough abstracted management of these compute resources... yet. But there's enough money and desire for there _to be_ that I know we'll get there.

<comment><USER9> > The holy grail (for some companies) is really something like Azure AKS + > Azure Container Instances. No instances to manage...

Google Cloud have been having that since before it's being called Google Cloud -- I mean Google App Engine. It has all those features, and with its "Standard" environment you don't even need to build docker image.

<comment><USER10> Cloud Run is even closer. App Engine Standard requires you to use the sandbox, App Engine Flex is tied to VMs, but Cloud Run makes containers serverless:

[https://cloud.google.com/run/](https://cloud.google.com/run/)

...and since it's based on Knative, it's portable-ish.

<comment><USER11> I can attest that Cloud Run has been great for me. I literally "ported" over some of my apps that were already running in containers by replacing references to my existing env PORT_NUM to GCR's PORT and it just worked. It's been a life changer. Now if it could run non-http workloads, I'd be able to shut down every one of my VMs.

</comment></comment></comment></comment></comment></comment><comment><USER12> Just a reminder to check out the API deprecations on 1.16: [https://kubernetes.io/blog/2019/07/18/api-deprecations- in-1-...](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/)

<comment><USER13> > DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the > extensions/v1beta1 and apps/v1beta2 API groups)

That seems quite significant. I still come across those regularly.

<comment><USER14> You gave me a heart attack. I thought they were deprecating Deployment, StatefulSet… But it's only the old API versions they are deprecating, not the features themselves…

<comment><USER13> Sorry about that. Yeah I meant the old API groups that I still come across.

</comment></comment></comment></comment><comment><USER15> I enjoy Kubernetes because it weeds me out from all the people who aren't used to actually having to read docs to understand the layered concepts of k8s as a networking model, of which there can me multiple opensource Implementations.

The opsys bros I know who are used to hacking together docker-composes that are more insecure than your grandmother's internet explorer browser in 30 seconds and calling themselves geniuses fail miserably when they are left to design construct and optimise secure kubernetes clusters and elegantly port a variety of full stack web applications in a coat efficient manner.

It requires planning and design. Just because you haven't invested hundreds of hours into reading the docs.and testing, and building k8s clusters for which the docs are incredibly useful...

Also "kind" represents the type of k8s object, like service or deployment. It's not ambiguous at all, it just requires reading to the third paragraph of "general Kubernetes concepts" in the Kubernetes docs to understand it.

</comment><comment><USER16> So, do we expect Kubernetes to ever replace Borg?

<comment><USER17> An ecosystem has evolved around Borg. Custom hardware, kernel, schedulers, telemetry, atomic clocks, networking, security, management... have all evolved around Borg proper to meet the "enterprise" needs of one of the largest enterprises in the world. It has many niche (i.e. not generally useful) cababilites built to service hardware melting XXX megawatt applications like web indexing, gmail, colossus. Even if Kubernetes targeted this customer, Borg has a significant head start. At this point the Borg ecosystem is almost old enough to by cigarettes in Mountain View.

<comment><USER18> Custom hardware? What kind and how is it related to Borg?

</comment></comment></comment><comment> _-___________-_ Great to see IPv4/IPv6 dual-stack support in this release, if only in alpha state.

</comment><comment><USER19> My biggest quarrel with kubernetes is that its API Reference often contains broken link to non-existing documentation page, usually pages that have been moved somewhere else (but who knows where?).

</comment><comment><USER20> A question on endpoint slices:why dont they send patch updates? A patch is the delta that changes an object instance.

<comment><USER21> Because safe generalized PATCH operations require the client and server to agree on the immediately prior state and the order of application of patches to avoid creating "Frankenstates". They're not a good general purpose API building block.

<comment><USER20> The client could do a full list request when it starts to get the baseline and then listen for patch updates.

That would be kind of an operator in reverse.

</comment></comment></comment><comment><USER22> that owl looks pissed

<comment><USER23> That's Captain Kube. More info at [https://phippy.io/](https://phippy.io/)

<comment><USER24> What the actual fuck.

<comment><USER25> Cartoon giraffes in general look very disturbing to me. Generally the length of the neck and legs are about the same but somehow every cartoon giraffe has amputated legs.

<comment><USER24> The horse with dwarfism and hightops is making me uncomfortable. But the gopher will haunt my dreams.</comment></comment></comment></comment></comment>