It’s cheaper to build multiple native applications than one responsive web app | Hacker News Reader

It’s cheaper to build multiple native applications than one responsive web app

hueniverse.com

629 pointscdnsteve304 comments

I don't think that's remotely true if you keep the responsive web app simple. YNGNI and KISS and what not.

I've been doing this for over ten years. In that time I've seen large web applications built for under 4k; I've also seen massively overbuilt simple applications go for 50k+. It comes down to often how needlessly complex you make the stack.

If you stick with solid simple guaranteed tech instead of cutting edge you can knock a web app out relatively cheap and easy.

When it comes right down to it, 95% of web apps have two jobs. Present text to the user, take text from the user. Everything else is a nice to have. HTTP has been doing those two jobs amazingly well for decades. It's a solved problem, don't make it harder than it needs to be.

Lastly: Don't fight the browser. Design for the browser. Responsive is easy if you design for things to flow as the browser would have it. It's one of the biggest mistake I see so often. If a design requires you to fight the native behaviours of the browser, it's likely a bad design. Fight back against that junk, it just makes future work that much harder.

tl;dr Develop for the web of a couple years ago and not the web of today. It'll save you time and headaches.

And simple apps are absolutely trivial to build native.

My favorite comment here. People are trying to resolve too many solved problems. Life is much smoother when you're not obsessively teetering on the bleeding edge.

I think the author is already addressing this:

Yes, you can build 2007 websites much better now. They will be consistent across platforms and perform great. But my 12 year olds don’t want 2007 websites. They want 2016 apps.

12 year olds don't have money, I would wait till people are at least 16 to care if they use my app...

The toy industry would like to disagree!

I empathize with the sentiment, particularly with open source and professional tools. But in mobile gaming and learning, parents are big spenders. Even in 2013, parents of children aged 6-12 in the U.S. spent $2.60/mo on mobile game apps or mobile in-game items.[0] Also I'd guess that children under the age of 16 contributed largely to the success of Snapchat and other such apps.

[0]: http://digitalkidssummit.com/2014/10/01/kids-6-12-in-the-us-...

That may even be true to a point but folks have been beating their budgets bloody against the design limitations of current web display technology for as long as I've been making websites (~15 years). This isn't a new rant.

Sure, but "2016 App" and "2007 App" are not monolithic design choices. If you can decompose those things, you can keep the important bits and throw away the peacocking.

Just a simple example: it's trivially easy to make large, flat shaded buttons on the web. That's going to be more familiar to younger users than native web buttons like those on HN.

However, there's also spending weeks to make a web button that animates smoothly from one container to another and has a SVG icon that morphs into another different icon with magic sparkles. Doing that on the web will require grossly perverting the DOM and all of the web interaction expectations.

A lot of the things we consider "Just 2016 App Things" are performances that native app builders have to do to give clients a reason to believe their $300/hour is well spent. No real value is produced except "design" awards for the shelf.

> is largely just a thing that native app builders do to show off and give clients a reason to believe their $300/hour is well spent

I recall an article by Zynga (maybe in Gamasutra? Can't find it now) that talked about user retention in relation to "rewards." They said that it's essentially a pure win to make every single action a user performs reward them in some way. Not a big reward—not a "points in a video game" kind of reward—but at least a pretty sound and an unexpectedly smooth animation (vis. "magic sparkles.") These things do make a difference, and it pays (in a competitive niche) for your app to do them. Just like B2B apps are sold mostly on checkbox features, B2C apps are sold mostly on how pretty they look doing their job in the app-store video.

The talk juice it or lose, by Martin Jonasson & Petri Purho, is all about this. Gotta be one of the best talks for anyone trying to make things interactive that also feel good.

https://www.youtube.com/watch?v=Fy0aCDmgnxg

Wow, excellent talk. I'm generally wary of these kinds of cosmetic changes, but the game really did look and feel so much better at the end.

To argue the case of the middle ground, it's perfectly possible to give the impression of a well animated app without breaking HTML's layout and constraints everywhere. Simple, non-obtrusive animations can give your interface a ton of "app-like" weight, and avoiding the complexity makes it easier for browsers to render, and also generally less expensive to develop in the first place.

If it's possible to do it with the new CSS animations (which should be reasonably well accelerated on modern browsers) and gracefully degrade by... y'know, not having the animations play, that's probably the ideal compromise right there. If you start restructuring your DOM in the name of easier animations or flashier effects, you've gone too far.

What does that even mean?

I seem to recall the median number of installed monthly apps sitting at zero for some time. Are you sure that "they want apps" or is it just that they're using the same few apps and web for everything else?

I think you're referencing the 2014 U.S. Mobile App Report by ComScore.[0] For a 3-month period in 2014, 65.5% of U.S. smartphone users download no new application each month. (see figure on page 6) I didn't see any more recent stats, at least without paying/signing up.

[0]: http://www.ella.net/pdfs/comScore-US-Mobile-App-Report-2014....

To be honest, this sounds like something we should never encourage as an industry. It promotes inauthenticity and chasing the shiny rather than making substantive improvements.

I'm going back to my Emacs editor. ;-)

What exactly differentiates a "2007 website" from a "2016 app"?

Google maps was way better then. A little less screen for viewing the map, but way more usable.

I would have agreed with you a few months ago, but the latest big update made loading the map and scrolling around it much, much smoother and faster. Finally they did something right.

Touch screens and gestures for one thing.

Web supports this via touch* events

With a little practice, you can do it with newer tech too... I've banged out several small apps using react+redux on webpack+babel, and it's gone really smooth and came out really light and decently structured.

Practice sounds like exactly what OP is trying to avoid. Also, you're talking about small apps. And also, webpack is the most incomprehensible waste of time that I've ever encountered in development. No hyperbole.

My point was that if you're keeping up on your tooling knowledge, it isn't so hard to bang out something quick/small. If you aren't doing it as often, then the difference is smaller in terms of impact to use newer tooling.

Regarding webpack, there aren't wholly better options yet... I'm sure there will be, but for now, it's pretty nice.

I have been doing front end for a good 8 years now, and I stopped finding benefit in most of the newer tools since Gulp and SASS, with the exception recently of RiotJS.

I am not against people trying to push front end technology forward, but it feels like we're just inventing a thousand different wheels when the first wheel wasn't really lacking much so long as you knew how to use it.

I am wary of any new JS library as if the past many years are anything to go by, it's practically technical debt the moment it hits v1, if it ever does.

I think the benefit of using webpack/browserify for bundling modules and writing modular code is pretty compelling...

It is, but it is a lot of tooling and knowledge overhead for a problem that can often be solved using whatever backend framework you're using. Or even no framework at all.

Laravel for example, it is very easy to only include JS files you need on a given page and make them modular using even vanilla JS.

You can even concat and minify it all, and it's all cacheable and idiomatic to the framework.

I guess the main issue is if I am spending more time on tooling and configuration of all the different parts of a build process then I lose the efficiency gains. For something like webpack there are no efficiency gains to begin with, as you can write modular JS without it.

It definitely has it's place and I am sure if I were exclusively a frontend dev I might find it more compelling.

But I can achieve clean, modular and reusable JS without it so it's one less tool I need to worry about.

Thank you. I thought it was just me finding webpack confusing.

What would you consider the web of a couple years ago/solid simple guaranteed tech?

Rails and jQuery. I've had so much success with those technologies, it makes me weep to watch the HN crowd shun them.

I find the premise of the article wildly incorrect. If we had to split my current 9 person company (building a JavaScript based app that runs in the browser) into an org with Android and iOS native projects, we would easily need at least 3 more devs. Arguably more. And those devs would be dedicated to their respective native Swift/ObjC and Java code bases, completely unable to help us build the base webapp.

Not to mention that every time we add a new feature or change something in the web app, that change now needs to be duplicated in two native code bases as well.

If anything the opposite is true: you can only afford to build native apps as a larger company.

It's YAGNI. YNGNI is unpronounceable.

YNGNI: /'iŋ-ni:/

The word you're looking for is inpronunciable, and it's not exactly as though "YAGNI" is some shining example of pronunciation to begin with.

Keeping the app simple is one thing; but if you want it to also be a design standout, you want to tweak things to be just right and this is a time suck -- the thing he talks about where doing something on one browser to prettify things breaks things on another browser. Making a internal corporate CRUD app is one thing; but making a end-consumer app that appeals to users is an entirely different beast.

I hope you are correct. For my startup, I've assumed you are correct.

Since my startup is my first Web site, I'm no expert in the issues in the OP here. So, HELP!

Guys here who know more than I do about Web apps on different Web browsers on different client devices, which is nearly everyone on HN, help me out here -- am I on or off track? Where am I going wrong?

So, what I've built is just a Web site (Web app). For the code to run in production, it's about 20,000 programming language statements in about 80,000 lines of typing. It's nearly all in Visual Basic .NET 4.0 with ASP.NET and ADO.NET.

For the user's browser, the user interface (UI), and user experience (UX) the site is all old and simple, dirt simple.

My guess is that the Web pages should look fine on any device with a Web browser up to date as of 10+ years ago.

So, the site is just simple, standard, old HTML and a little really simple CSS. The CSS is all in the same file as the HTML.

Microsoft wrote a little JavaScript for me, but I never wrote a single line of it. There is no use of Ajax. So far there is no use of cookies.

So, for one Web page, what goes to a user is just one HTML file with CSS, a small JavaScript file, likely standard from Microsoft, and a file for each of the images.

The fonts are large and standard. The colors are simple with high contrast.

For images, there are ads in the two standard sizes, banner ads 720 pixels wide and 90 pixels high and other ads 300 pixels wide and 250 pixels high. Otherwise the images are just a few, simple, small PNG files for logos.

The only HTML controls are single line text boxes, buttons, and text with links. There are no roll overs, pull downs, pop ups, or icons. There is no auto-complete.

The natural language on the site is all English, but it is all very simple, and the user interface is so simple that a person with no knowledge of English should be able to learn to use the site in less than 15 minutes.

The page layout is all done with just tables with all widths fixed. E.g., each Web page is exactly 800 pixels wide. Since there are both horizontal and vertical scroll bars, the Web pages should be usable in a window as narrow as 300 pixels wide and 200 pixels high.

Each Web page sends for about 400,000 bits (except for the ads from ad servers).

The reason for people to use the site is for the information it provides. The site is quite interactive, and there is an iterative, game aspect as in games where wander through tunnels with clues and looking for coveted prizes. Maybe for some users the site will have an addictive quality.

From what details I've given, is it likely that the Web pages are simple enough to work on nearly all current Web browsers on whatever client side devices?

Where am I going wrong?

Thanks.

You have to tell us what is wrong first, in other words why do you think you're going wrong? There is nothing wrong with what you've described as far as I can tell. But what issues are you having? Users not going to your site? Likely not a tech problem.

Thanks.

My site is not live on the Internet yet. On my development computer, it appears that the site works as intended, but I'm still testing, say, alpha testing. Then when I invite in people, call that beta testing.

For what is "wrong", I am just guessing that I might have encountered some of the problems mentioned in the OP.

Or, maybe even the simple, old HTML, CSS, and JavaScript I'm sending to the users might have problems on some Web browsers on some mobile devices? I don't have a mobile device, certainly not a big collection of them, for testing. So, likely the beta test will be the first real test if my simple, old HTML, etc. will work on various Web browsers on iPhone, Android, tablets, old/new laptops, etc.

But no doubt other Web site developers here on HN have already been there, done that.

Or, for the question, what precautions, considerations, limitations, etc. have to honor to have a relatively simple Web page display and act as intended on a wide range of client devices?

Thanks!

As long as the people developing your site have been keeping up with things since the mobile web became a thing (several years), it should be expected that they can develop an app that functions well on just about any device that will run it.

This is common, required knowledge of developers. They should be testing the site on as many devices as possible, and developing it with cross-browser capabilities in mind and tooling that does it for them. You can check yourself to see if it works

There is no excuse for not being able to develop a consistent experience across as many devices as possible. And it sounds like the poor OP just got a lazy developer.

Except in this case, the developer is me, and this is my first Web site!

Ok, then you need to learn the things I mentioned. It is not as hard as OP suggests. Based on your comment history, you seem more than capable of figuring this out.

Thanks. From the reactions here, it seems that my initial guesses were correct or nearly so -- for really simple HTML, CSS, controls, no ambiguity about the layout, and nearly no JavaScript, what I'm sending will work well enough on nearly any Web browser nearly all the time. At least for now in my testing, I will assume that is so and, thus, leave testing on relatively unpopular Web browsers for much later, likely after I go live. Thanks; I just slimmed down the alpha testing!

Given the karma and the comments of the previous years I think you're being somewhat ironic. 400,000 bits, table layout and all the rest, a 1997 startup? :-)

So, if what my server is sending the user clients looks like 1997, then the people writing Web browser software have had 2016 - 1997 = 19 years to do the same things to the same HTML and CSS.

So, sounds like my code stands a good shot at looking good on the devices of nearly all the users.

Okay. That's what I was hoping for!

The discussion pages of HN, which is somewhat 1997ish (table layout), didn't use to look good in Android Firefox. It's a little better now.

> 95% of web apps have two jobs. Present text to the user, take text from the user. Everything else is a nice to have.

I think this misses a key point - with mobile sites to be useful they have to be convenient enough to not make me wait until I'm next to my keyboard to do the task. Being convenient and easy to use is THE CORE FEATURE of mobile web apps, because they compete with using a full size web page on a laptop, in a few hours.

Take a simple, and pretty common scenario as an example -- booking an airplane ticket. The text I'm inputting is my name, address, frequent flyer number and credit card details, plus some dates etc. Also the same data for family members that are flying with me. Not a ton of data but it's a lot to type on a touchscreen and parts of it is sensitive information.

With the native airline app my details are pre-filled if I ever booked a flight before. With a web app the pre-filling of data is either dependent on a web login to the site (not acceptable) or on a browser form filling wizard (hit and miss, at best). I can book a ticket for me and the entire family with 10 taps on the screen in the native app, and on a mobile web app I have done over 30 taps before I even logged in!

I could of course book the same ticket using the mobile web app - but it's a pain. The native mobile app is way better than a desktop web app, and the mobile web app is only ever as good as the desktop web app, but always lacking in input because the keyboard is missing.

So yes - mobile web apps can be easy. They don't need a lot of fluff to get the work done. The problem is that they then are often completely unnecessary.

Even something as simple as typing an email address is a chore on mobile, so logging in in CompanyX using email+password is usually enough to postpone my transaction with them until I'm at my proper keyboard.

Seems like you're deferring one dragon for another.

Deliver the project got easier; "Control the customer" got significantly harder. You've now got someone's app store in the middle of your customer relationships and are exposed to approval drama, various forms of revenue squeeze, and other meddling from the platform owner. What happens if the folks running the platform decide to launch their own offering?

Speaking as another small developer, our solution to the cross-browser feature support is simple: anything that doesn't run on most modern browsers doesn't make the final design. If the customer doesn't bite on basic design, we don't expect a miraculous shift with the latest widgets.

Apps don't have to be downloaded from stores, thought that certainly does make things nice.

On iPhone they do, and I doubt you'll have much luck getting the average Android user to side-load either.

Circumventing the App Store on iOS is problematic at best...

Not really. It's called the Enterprise Program. While this is for 'enterprise', you can also use it - and Apple allows this - to distribute _outside the App Store_.

A few years ago I built a nice sms delivery system for installing an app I was working on. Text anything to our number (we had multiple numbers thru twilio based on market). App replies back with a download link. Install. It worked perfect and we could actually tell who requested the app and who installed it. We had around 75k users installing. Not millions, of course, but still, not too bad.

So, it is possible. We also did not have to wait for any approval process. And when the app started up, it checked for an updated version on our system. If there was, the app would then prompt the user to start the update. It was a very nice flow and we had many comments from users telling us that 'it just worked'.

This was app pre-iOS 7 and automatic app update, but it's still being used today.

As far as I know, that's against the program's ToS, and your certificate can be revoked at any time.

Apps stores are crippled excused for real package management. In the open world, you can import someone else's key and repository and install their packages. In Play/iOS/Windows you have a single provider. There's no bug tracker to add your packages and no way to add a stable and unstable channel..unless both apps are in the same store ...and every beta release then has to get approved.

It's maddening. I wrote a thing about it and other Android issues: http://penguindreams.org/blog/android-fragmentation/

iOS and Windows Phone devices may be limited to a single package provider, but Android devices are not. I've had more than one store on my Android phones and tablets for over five years now. And, yes, I'd love it if there were a standard way to include signing keys for additional stores so that installations were seamless, that's not a significant problem in practice.

ATM's at casinos and clubs can charge $5+ dollars for a withdrawal, but that doesn't make it a viable solution for even %10 of ATMs.

In practice, they do. On iOS, you can only go through the App Store. On Android, while you can sideload, the vast majority of users are going to expect to get your app from the Google Play Store, and not bother to check anywhere else.

I can speak with some knowledge of a not-insignificant B2C company -- not my current gig -- that went down this exact same route some years ago.

Swore off mobile web in favor of pushing people to the app, because app conversions were much higher.

A satellite office broke away from the fold and implemented a responsive mobile site, immediately increasing their bottom-line revenue by 30%... and that's before doing any sort of conversion optimization.

The main office followed suit shortly thereafter... with a new head of engineering.

Native apps are no easier or harder to build than web apps. Equivalent level of difficulty in my experience, with apps being slightly harder because end-to-end testing needs to be done almost completely manually, and because the release cycle is partially outside of your control.

But for most businesses, you really, really do not want to neglect the mobile web.

Yes, conversion for in-app users is broadly higher across the board. But that's not because conversions suddenly spike when people use an app. Rather, your most dedicated users -- the ones most likely to convert -- are the ones that will install an app.

For the rest of us, if it's "app or bust", we will pick "bust".

As a consumer, I deal on an annual basis with probably over a hundred different companies. I do not want an app for each of those companies. And if you force me to download an app from the get-go, I will go to your competition.

exactly, http://www.recode.net/2016/6/8/11883518/app-boom-over-snapch...

Alternatives are webapp's or even building chat bots/apps on messenger platforms. This progressive mobile webapp example is impressive http://www.flipkart.com/

"You want mobile notifications? Sure, but not on mobile Safari."

You can do this with PhoneGap.

"Multiple line ellipsis? Sure, but only on webkit."

Okay, yeah, this sucks.

"Consistent rendering size across browsers? Just fuck off."

This is probably your fault.

"We fix a layout bug on Safari and break something on Edge."

This is probably your fault.

"We change font size on Chrome and now all you can see on Firefox is the letter F."

This is probably your fault.

"How about hiding the address bar or controlling swipes from the left edge of the screen? Don’t be stupid."

Stop trying to make the browser not a browser. Users hate when you hijack expected behavior. (See: Imgur.)

"Oh, and don’t get me started on all these new custom mobile keyboards you can use and how autocomplete can fuck with your input box events."

You can disable autocomplete. Did you mean predictive word suggestions?

TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose."

This is probably your fault

That's the point of the article. Getting these things right on the web is non-trivial (and therefore expensive).

Ehhh.... These examples seem really amateurish to me. You'll run into lots of issues developing for the web, sure, it's not perfect. Especially web "apps" that need to work cross-browser. But the listed problems stem from not understanding your platform, not problems inherent to the web itself.

To make an analogy, it's like the equivalent writing a native app where input and UI rendering are handled by the same thread, and then complaining that input doesn't work during intensive operations, so javascript / the web is better for apps, and native is terrible.

It's also an unfair comparison. These statements:

> We made a bet on the web. Built a responsive site for desktop and mobile and tried to avoid the native app space (still are).

And then later

> One app for iOS, one for Android, and I got over 90% consumer coverage. I can even use a framework to share work between the two.

So originally with the web, they're trying to target Desktop Chrome, Desktop Safari, Desktop Firefox, Desktop Edge, Mobile Chrome and Mobile Safari with one codebase. Then they move to only targeting Android and iOS (native mobile only) with two separate codebases? They could have just as easily targeted mobile Chrome and mobile Safari, and shared 100% of the code.

I'm not sure what they mean by a framework to share work between the two. If they're referring to something like Xamarin, I hope they've at least tried it before assuming everything works great. They're very unstable, and you still need separate codebases for your views, typically more. Ironically, the most stable ones of these I've tried have been web-dev based frameworks.

tl;dr: "It's cheaper to make an app for 2 platforms than for 8 you don't understand."

I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction?

Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it.

> I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction?

You generally only have to write it once. But you've gotta write it right. The other attractions are no installs, just visit a web page. No users with "out of date" clients, you just serve the updated page to users. A sandboxed environment to run in. Ease of sharing (URLs). The DOM, while slow, is also rather nice if your layout model resembles documents. There's a million reasons why web might be the better choice. There's also a million reasons to prefer native.

> Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it.

Usually these are showing off new features available in the browser that weren't present before. And they can do a hell of a lot more than let you interact with it in some limited way, or move an object. How about an entire 3d Modeling Application in your browser? (Warning may lag a mobile device or slow PC)

http://www.3dtin.com/

But these are crazy, cutting-edge things that are still best done natively. Most of the time you're not making a 3d Modeling application. 99% of the time an "app" is something that shows text and images, and takes text (and sometimes images) from the user. You can make it super flashy, and that's where a native app would excel. But does it really need to be flashy? Does a cruise line's ticket booking app really need to show water flowing across the screen while you load the next page, and a tugboat pulling in prices? Or are these gimmicks that will just end up pissing off the user?

I guess I really just disagree with the blanket statements by the author. Native probably was a better call for their app, but they don't focus on why. Just that web supposedly sucks... Instead of learning the strong suites of web and native, and why they thought web worked for their app but it didn't, they've "learned" to not touch the web. Which I think is the wrong lesson.

That's because the web is a terrible platform to develop for - because it's essentially a text-with-graphics platform with about 20 million different extensions, standards and so on to deal with. So the choices are:

1) deal with it 2) pick a better platform 3) try and come up with a new platform which is broswer-like but where there is predictable, obvious behaviour on multiple implementations of the platform, and where the platform supports, out of the box, all the sorts of functionality you'd like for a modern app. If your platform is missing any of the APIs you have available on, say, Android or ios you're going to struggle to make a web app as rich as, say, google maps, or whatever.

I'd for for 3 but I guess it's hard because all the people who care are too busy trying to keep up with which framework to use, or centering text, or whatever.

For a totally new project, especially with React and React Native, it's not trivial to get things right, but it's not that hard either. Technically it's not "one app", but if you build them in parallel and you know what you're doing, 90% of the codebase can be shared.

The author is putting forth a false dichotomy between "write one web app that works on everything" and "write a new app from scratch for every platform." The right answer in 2016 is a hybrid approach.

Couldn't agree more.

We are building a product that runs on iOS, Android, Web, Desktop (using Electron) and Chrome OS, with Firebase, React, and React Native. A lot of code is shared among all platforms.

Did we read the same article? What is this condescending bullshit. Nobody is arguing these things CAN'T be done, just that it's too much effort on the web, and the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable.

the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable.

The market has spoken. Doing those things is hard enough, people can charge lots for it.

That sucks. "Sucks" == suffering. Suffering == opportunity. (Deliberate Yodaism. Actually high market price == market opportunity.)

Which is why it's cheaper to build multiple native apps... which was the point of the article.

You seem to be laboring under the false impression that I'm disagreeing with the article. I'm agreeing with the article. I'm also pointing out that this situation would indicate there's a market opportunity somewhere. (In the words of Jeff Bezos: Your margin is my opportunity.)

There are a lot of those little frameworks that try and bridge all this together: PhoneGap, Titanium, etc. They're all varying levels of terrible (unless you want to make games, in which case Unity mobile is a pretty solid bet).

So there is a market, people are trying to fill those gaps, and yet none of them seem to be able to bridge the gap in such a way that devs prefer maintaining two or more native apps over one that compiles for multiple devices with a common framework.

So there is a market, but it doesn't look like it's an easy problem to solve.

The "condescending bullshit" is the title of the original post. I read the title "the fucking open web" and thought that 54mf's response was pretty diplomatic in comparison.

This is also what I took from the article. Everything they're wanting to accomplish is certainly possible, but instead of just knowing the ins and outs of each platform, you have to know the ins and outs of each browser AND how each can affect the other browsers.

Beyond this, it is clear to me when an iOS-minded developer creates a web app that ends up on Android. Each have their own specific styles, and this gets lost with web apps.

Not to mention the effect of time. The Web is not a stable application environment, and you may get caught in limbo, where the old way to do something is technically deprecated, but only one browser implements the new scheme, and only in nightly builds and even then only if you launch with --please-segfault-hourly. But using the deprecated API means at some arbitrary point in the future your working code will stop working.

The Web rarely deprecates features. Browsers still have to display the Web of 1995.

> The Web rarely deprecates features.

No, it rarely removes deprecated features.

How about the Web of 2012?

WebSockets changed wire formats multiple times before we settled on something. Last I checked, the API still isn't final, and changes in browser behavior forced a project I was on to abandon it for socket.io. Web Audio has been through at least one breaking rewrite since 2012, and still isn't finalized.

Sure, '<h1>' still gets me a big, bold heading (probably, subject to CSS), but playing a sound file without plugins is still bleeding edge, and subject to arbitrary breakage. But we've broken plugins (for the best, eventually), so the old solution to that problem no longer reliably works.

> Nobody is arguing these things CAN'T be done, just that > it's too much effort on the web,

They're saying it shouldn't be done, or that it's possible and if you can't do it you're a lame developer. I didn't see it as condescending at all.

I read it as entirely condescending. The several "It's your fault" replies? Nothing but condescension.

> and the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable.

Really? More unaffordable and unavailable than at least one native developer for each platform you're targeting? I find that hard to believe.

Ye gods people.

The entire article is saying "I used to believe it was too expensive to do native apps so we did web, I now believe I was wrong, even though it may seem cheaper at first the costs of the web are far less predictable and it's now economically better to just do native apps"

But the author didn't actually compare the difficulties and costs of web development to native development. The article just lists a bunch of (debatably valid) difficulties of web development. But most (all?) software development has difficulties and annoyances.

What I thought the author was trying to say was that you can make a car that floats. It's just a much better understood problem to buy a car and a boat, then call it a day.

"If you have a ship that can carry a tank, why not just put guns on the ship?"

I'm available... and semi-actively looking... ;-) But I'm not cheap. That said, I provide great value.

I've been writing web based applications for about 20 years now. It's a lot better than it was in the late 90's and early 2000's, so stop bitching or get off the lawn. (sarcasm) Seriously though, I'd much rather deal with webpack, babel, react, redux and the like than angular 1&2 (just feels like a decade old solution now), and heaven forbid having to ever look at an <ILayer> again, or breaking up forms dynamically in the v4 browsers.

Yes, there are a few features not broadly supported, but there is also tooling that makes web dev as good, and in some ways better than app dev (though less than natural, and all out performance on a complex app is hard)... all of that said, it's a VERY valid option for many/most sites/applications.

But do you provide an amount of value that offsets the cost of two or three completely-adequate devs working in parallel on mobile apps? ;)

That's the killer.

This. +1 for PhoneGap, we are sharing a single codebase between a mobile web interface, iOS app, and android app and have managed to keep it fairly clean.

> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose."

Complete agree on this, and I think that it is the most important point here. It's similar to the when people try to code in one language and complains that doesn't behaves like the one that they are used to. Browsers are designed for a function, or a lot of them, force your design ignoring web needs is going to produce a buggy hard to maintain software.

> "Consistent rendering size across browsers? Just fuck off." > This is probably your fault.

As someone who has spent an embarrassing amount of time debugging kerning differences, line spacing, and obscure letter size differences across IE/Firefox/Chrome I can enthusiastically say, it might be his fault but I doubt it. Different browsers do things differently and in cases where things must be the same, this is an expensive and time-consuming problem.

Can't a UI be designed such that minor fontsize differences aren't a disaster?

Yes. But the article paints the picture that these weren't minor font size differences.

"We change font size on Chrome and now all you can see on Firefox is the letter F."

They're doing something funky. They can call it a "2016 website" but the problems described in the article don't really make sense to me as anything but design-related. Now, I know that you can't design your way out of every problem, but if they're going to use IE6 as a hellmouth and not IE8, they may be using a greater number of bad practices than necessary.

For a while, Firefox mobile would render different parts of HN's text in different sizes. At first I thought it was a mobile-only feature, but that would be odd for HN to do. Nope, turns out it was a Firefox table-something layout font issue. Seems fixed as of, perhaps 6 months ago?

Searching around also finds this answer pointing to a now-dead link saying Chrome used to have known issues with "consistent" fonts on sites like Reddit.

http://stackoverflow.com/a/19988987/27012

It is actually a feature, called "font inflation"[1], that tries to find the main content text on a site not designed for mobile and make it a readable size. It just wasn't doing a good job figuring out which parts were the content.

I would guess the recent improvement is due to the site itself being fixed – it now uses a "viewport" meta tag, which I don't think it did last year.

[1] http://www.jwir3.com/font-inflation-fennec-and-you/

Yep. Features like this are basically why developing tightly-controlled UI experiences on the web are a garbage fire.

For a tightly-controlled UI experience, you want a thin, predictable framework that you can build your experience on top of. The web is the opposite of that. Big, big chunks of important detail for user experience are not specified in the RFCs and standards themselves.

Take CSS as an example. The first thing most web development frameworks will have you load is a CSS that sets the style for everything to some known defaults. If the web as an app development framework had been designed for a controllable experience, that would be unnecessary. But the web wasn't designed as an app development framework; it was designed as a heavily user-configurable presentation layer for standardized format of content.

While I generally agree, I'm not surprised mobile browsers did weird things with HN. Look at the source, it's nested tables with expanded invisible 1 pixel gifs used for indentation.

I've not designed HTML since the early 2000s but that was an easy, workable, way to do layout then and should still work now. HTML takes are just weird and require tricks like that to work. I understand the current preferred way is creating a grid via CSS.

>This is probably your fault.

I wonder if it is more arrogant to claim that things are broken or to tell someone its their fault without even knowing what they're trying to do.

> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose."

That's literally his entire thesis.

There's been a ton of effort invested in trying to make web apps capable of competing with native apps, and his point is that it's still simply just not feasible. It's cheaper — and more importantly, costs are more predictable — to develop a native app for every platform you want to support, than to develop a single modern webapp of equivalent quality.

PhoneGap? I thought the point was the original author didn't want to ship shit. PhoneGap apps are generally terrible. PhoneGap is the preferred solution for CIOs that want to save money but end up delivering a glitchy crap product. JavaScript isn't the catch all savior many JS people seem to think it is.

CSS and JS animations are children's toys compared to Metal on iOS. You can make a far more beautiful and smooth experience with native apps than anything ever done on PhoneGap.

You want access to a new iOS API on PhoneGap? You have to wait until it's public. If you want to upgrade your app for iOS 10? You have to wait until iOS 10 is publicly released.

Anyone using PhoneGap is almost certainly someone who is unwilling to learn Swift. Nobody actually thinks PhoneGap is better.. It's just a convenient crutch for those who are unwilling to invest the time to do it right.

If you have to ship a mobile app because of some executive vanity for a mobile app-- go ahead use PhoneGap. But if you actually want to write the best app possible, delivering a great user experience (as well as device experience,) then learn the real thing.

Also, you missed the point of the article -- obviously the problems are 'his fault.' The point is that all of those problems are more painful than simply building a great mobile app.

The issue with your comment is that it is based on the idea that supporting a platform is the goal. As per your value metrics, the more platform-rich the experience is, the better it is.

This is however not how business works and not how businesses work because it is not what they need. What they need is to transfer value to move their business forward. It is also the only thing they (should) want.

Full Android or iOS support is not what smart business leaders aim, I would tend to say it is the opposite.

I don't care for 1 second about the Metal/Swift you talk about when I can have people get their credit card out with an HTML page without CSS.

> Stop trying to make the browser not a browser. Users hate when you hijack expected behavior.

Another point against making web apps: users have stricter expectations about them.

>> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose."

The first wave of designers who targeted print had the same trouble native app designers had and ended up building big blobs of flash applications.

Native app devs moving the responsive web route face similar troubles. I guess they can alleviate most of the cross platform, multiple screen and accessibility compatibility by relying on a framework.

In the mean a lot of native apps lack support for accessibility, multiple font sizes, and color schemes, ability of bookmarking a certain screen, ability of moving back and forth between screens, ability to open multiple pages (or screens) at the same time, better caching when mobile and offline, a way to hyper link within or across apps, support for various screen sizes from large to very small. So it could be better the native-to-web refugee to focus on the advantages of the plain old web which apps lacked.

> You can disable autocomplete

You can, but it makes you pretty much the literal devil.

Don't disable my autocomplete.

> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose."

It makes him grumpy because he can't get users what they want.

You can't disable auto-complete in a web app (or can you? If so, I'm sure it's different for each platform).

We're not just talking about iOS and Android. You've got Chrome mobile, the ASOP browser, Firefox mobile, whatever shitty browser the carrier wants to include and all the various versions of those that will never get upgraded.

Personally, I really like the ranty tone of this article. I don't think it's unjustified at all. The author's frustrations are very valid.

It seems doable https://developer.mozilla.org/en-US/docs/Web/Security/Securi...

""Consistent rendering size across browsers? Just fuck off." This is probably your fault. "We fix a layout bug on Safari and break something on Edge." This is probably your fault. "We change font size on Chrome and now all you can see on Firefox is the letter F." This is probably your fault."

Seriously, that's your answer? There are problems, and your response is to blame the user, rather than admit that these are problems that simply should not exist?

Even if this is true, I doubt it's a wise idea, given that the average US consumer downloads zero apps per month:

http://qz.com/253618/most-smartphone-users-download-zero-app...

Unless you're in a very fortunate niche, you can't afford to not do the web. You can afford to not do apps.

I don't like how the author mocks other people who make decisions based on money over ideals:

> That group, btw, has mostly sold out taking high paying jobs at Facebook and Google, and have not heard from since

...but then later justifies his argument to forsake his ideals because "hey I've got a business to run":

> I don’t need you to troll me on Twitter and tell me how I’m betraying the web and the free fucking world. I am just trying to keep my startup going.

I can totally relate to some of this.

If you take a look at Meeker's 2016 Internet trends report that came out last week, you will see that 3 apps dominate 80% of the usage on phones. I decided when I started my food side project a year back, that I was not going to do a native app.

I have been trying to make the front end look better, but I did not want to use very heavy frameworks, so I settled on using the SASS mixin library Bourbon.io along with the grid and a few others the company provides.

The css that is produces is very tight, and I can save on developer costs. I should say, save on finding another front end developer as the one I was using took some money and ran.

I don't really see how user time-share is relevant unless your goal is to start a social network/messaging system.

80% of user time is spent in those 3 apps, that doesn't preclude very profitable apps from being developed. After all, people spend 16+ hours a day at home/work, but there are still plenty of reasons to open restaurants. Unless you profit directly from time-spent-in-app this doesn't seem like a consequential measurement.

See: Uber, pretty low on the charts for time-in-app but yet a massive business. Ditto Amazon, or GrubHub, or any number of other apps that deliver value to their users (and revenue to their owners) without long sessions.

Totally agree. The most money I've ever spent is on Tasker and AutoApps family of Tasker plugins, and I rarely even open them - they're the ultimate background apps, but they work, they work well, and they're very much worth the money I paid.

There is going to be some reluctance to download a new app. If you can get tons of VC money, and you can pour it into marketing, you can get people to download your app.

But I think user adoption is just that much easier if all they have to do is open up your mobile web app in their phones browser. You could always build the app later after you have gotten the traction and growth.

sass+bourbon.io (or similar combos like sass+compass) can help a TON with keep front-end dev costs down.

Some apps do benefit a lot being native, but as others point out you throw in the middleman app-store model instead of just dealing with the browser, and keeping your UI simple, clean, efficient and of-course usable.

Agree, but have you ever built a responsive drag and drop document builder? Anytime you start getting into mobile-specific UX on a responsive web page, it often becomes and unpredictable mess. Parallax scrolling isn't the best example, but it is a good illustration. Parallax on mobile browsers historically has been pretty glitchy and horrible. When a similar kind of UX interaction that's actually a necessary part of the app is done in responsive, it's generally very hard.

Really the problem with mobile web seems to be JavaScript.

I think this is a bit of "grass is greener" syndrome.

I developed web apps for 14 years before building ios apps for 5 years.

The last couple of years I've worked on both native apps and responsive web sites.

Both can be pains in the ae. But the pain points are different.

Both are moving rapidly. eg Ios: having to rejig xibs to storyboards was annoying.

Css: Supporting older versions of IE has been a pain.

I could go on at length but plenty of people have already done so.

Was just going to comment that "the grass is always greener..."

For example, here is something that was on the HN front page just a few weeks ago: http://clean-swift.com/mobile-development-projects-fail/

There might be something to the headline but the content isn't delivering.

1. You can't compare making an ios and android app to making an app for every bloody broweser, I mean you could just as easily built your webite to safari and chrome for mobile. You want a true cost comparision compare building an app for universal windows, and mac and linux. Of course if you reduce the scope of your app's access you are going to get reduced costs.

2. Building a messaging app is probably the least appropriate and one of the hardest things to build with web technologie( after a game). Use the appropriate technology for your app.

3. By your remarks on how costly mobile developers are, I'm guessing you've hired to inexpierenced web developrs. Get expierenced developers who know the limitations and best practices and you wont encounter so many issues.

"One app for iOS, one for Android, and I got over 90% consumer coverage"

What's the consumer coverage for Mobile Chrome + Mobile Safari? Giving up on total cross-browser compatibility doesn't have to mean writing native apps.

The coverage is probably pretty high, but you're limited by each browsers respective feature set. There may be functionality that you can't ship due to limits on multiple browsers. Other issues arise if you factor in sites which needs to take into account all browsers; You'll end up bloating your JS/CSS to handle all of these conditions impacting mobile page size. It can be done, if the product is fairly simple, but problems arise as you increase your products complexity and feature set. Native apps have their own set of problems with distribution and the web has it's own set of problems with performance and hardware API access.

"Giving up on total cross-browser compatibility" seems like it would entirely avoid "sites which needs to take into account all browsers".

Potentially, although I think that there are cases when it's fine. For example when I lived in San Francisco, my LTE speeds were insanely fast so it wasn't as big of a deal. Now that I'm in Pittsburgh, the LTE speeds here aren't as good so mobile web isn't as good.

Also on a desktop or laptop where you've got a good Wi-Fi connection most websites are really good. That being said, I still things like Tweetbot, Flume, and Airmail over twitter.com, instagram.com or gmail.com.

When you multiply that 90% consumer coverage by the percentage of people who will install your app when you ask them to, it's going to knock down your 90% pretty considerably.

Totally agree.

For users, I'm not sure how this is significantly worse than asking people to visit your mobile website. In my personal experience, people will search the app store for your mobile web application by default anyway.

If your product is an "app" in the functionality sense, then people are going to look for it in the "app store". Period. For user, it's actually a better experience than using Chrome/Safari.

I agree. Personally, I consciously avoid anything that smells of webapp and consider this to be a product of a lazy-ass company. Non-native applications pretty much universally suck, and it only shows that the quality/usefulness is not a goal.

This article might have had some resonance a couple of years ago. Today it's just not the reality. Mobile apps are running into major engagement issues. App Stores are loosing their value prop and running towards web-like SaaS pricing models (Apple's hand was basically forced here).

On the other hand, mobile web browsers are way better than they ever have been. Desire to maximize web performance instead of allowing bloatware JS and ad cruft is at all-time high of industry awareness. Many mobile apps are "hybrids" anyway. Basecamp 3's new mobile apps are good examples of how you can create a pretty solid experience with a sensible mix of native and web-based functionality.

In other words, the open web is actually in better shape now technologically than several years ago. If only the big VC-backed SV startups would see that instead of chasing their tails trying to grab app users' ever decreasing attention.

If you're a two person startup quit building on quicksand. Use stuff that works. Once you have some users you can start venturing towards the bleeding edge of what's possible.

Meh, supporting a couple of iOS versions and a couple of Android versions for a native app along with device specific quirks is as much of a pain as supporting Firefox, Chrome, Safari and IE. Also, maintaining two code bases for native Android and iOS apps is a massive investment compared to a single web app code base.

Well, Native could also mean transitioning over to React Native, Cordova, Phone Gap, etc

Ehhhh, I really haven't had these issues with any of the meteor apps I've made. Even getting swiping and full page animation transitions has been relatively simple. My experience is anecdotal, but I actually left being android developer to do mobile web and I've found the experience to be far easier.

Easier, yes. The tools for web development are awesome and amazing, but there's so many restrictions and limitations that come with the web. Maybe the web is the way forward, but native will be kicking its ass (regarding experience) for a long time.

80% of "experience" is micro-interactions, which are mostly nice-to-haves.

Similar experience here using Meteor + Ionic, exported with Cordova. I also feel like the skills I'm developing in web development are much more widely applicable than learning a particular mobile OS.

I often hear this. I tend tp agree but what exactly do you mean? That Javascript is used more widely?

Exactly this. I guess for people who have built their careers building mobile apps they couldn't care less about more rounded skills(in relation to web at least), its mostly full stack/back-end devs who know JS seem to state this. Not that there is anything wrong with that.

You hit the nail on the head -- I am a full-stack/back-end dev. Always prepared to learn the next thing (provided it's in javascript, hah).

  > Even getting swiping and full page animation transitions
  > has been relatively simple

This is telling. These things are FREE on native. Like no effort at all.

Comparing "responsive web apps" with native mobile apps? Really? What about cordova/phonegap/ionic?

Don't blame the web because you made a poor decision picking your tech stack (or hiring your devs). Nowadays a single webdev can ship OSX, Android and Windows apps with frameworks like Ionic... in weeks.

Starters (there are hundreds) help a lot: https://market.ionic.io/starters

Stuff like Cordova and Phonegap almost universally produce crappy apps. Doubly so if the person doesn't think they need to style the app for the individual platform, instead of just shipping the default (usually iOS) styling.

Shipping an app with one of those is almost universally saying, "I don't care about user experience, I just want to shovel something out the door as cheaply and quickly as possible."

> Stuff like Cordova and Phonegap almost universally produce crappy apps.

Again, don't blame the tool. Blame the bad usage of the tool. You're just saying: "Let's ban knives, assassins use them to do bad stuff!"

> [...] style the app for the individual platforms [...]

Ionic does this for you automatically. Surprise!

http://ionicframework.com/docs/v2/components/

It's easier to complain about the tools than acknowledge that you might be wrong about how you or your devs use them (because of unfamiliarity).

Truth is many people are shipping stunning apps in no time thanks to web technologies.

No, I blame the tool because it's a poor tool. And I'm not using them wrong, because I'm not using them. I do native apps, because I care about my user's experience.

> Yes, you can build 2007 websites much better now. They will be consistent across platforms and perform great.

There you have it. Using bleeding edge features will create a lot of problems. First you need to figure out what type of users you want to target, PC users with 24 inch monitors and keyboard? Or 12 year olds with iPads? But still, for your software to really work across as many units as possible, and continue to work for years, you have to look what existed 5-10 years ago, and only use those features that are still standard.

I have a mobile phone that no longer gets updates. It is HTML 5 compatible, so it should handle everything that is not bleeding edge, but still many web pages, for example medium.com does not work!

I remember being a web developer ten years ago, it was your professional duty do make sure it was pixel perfect on existing GUI based browsers and even look good on the text based ones. I think web dev's today is too quick to jump on the latest and greatest.

If you take a look at the browser features that existed 5-10 years ago, it's way behind the native phone app experience! It seems browser vendors totally missed the mobile explosion, and only lately have begun to catch up! Considering how fast the web tech moves now though, the future for web dev looks bright. I think that in in 5-10 years, the mobile browser experience will be on pair or even ahead of native, at least considering dev experience and cross device/platform support.

(note: I've met Eran a few times, he is very smart and I respect his opinion)

Note aside: this is one of those "it really depends" kind of situations. For many cases native apps are always going to be cheaper to build. For others the web is just much better. It seems like the problem Eran is describing is more of a labor shortage. It's really, really difficult to hire good web developers. I have no idea why this is.

> It's really, really difficult to hire good web developers. I have no idea why this is.

The obvious answer is the one given in the article: Google, Facebook, etc. can afford to pay good web developers far more than a small business.

One app for iOS, one for Android, and I got over 90% consumer coverage

However with a huge friction point of requiring users to download and install an app.

And not being searchable or deep linkable or shareable.

None of this is true. Universal links on iOS even allow the same links to work whether you have the app installed or not.

I'm not sure exactly what you mean by each of these, but at least in Android apps can register to open URLs. So you can search for and share, say, a Facebook link. Tap it, and it opens in the Facebook app (or the browser, or any other app registered to handle the URL, your choice!).

I think these are the definitions that he/she goes by:

Searchable: It being possible to find contents on the service via web search engines (Google, Bing, Yahoo!, DuckDuckGo etc.).

Deep linkable: It being possible to link to specific content on the service (and not just to the service as a whole).

Shareable: It being likely that your service as a whole is linked to. While you can share with someone that an app exists, it's far less likely that users will do so, because of the install-barrier.

And what you mentioned requires the service to maintain both an app and a webpage, so that doesn't work when we're talking about dropping the webpage...

So the criticism is that apps alone, without a web presence, cannot be "searchable" and "sharable". "Deep-linkable" is still possible; your app can handle and resolve URLs that another app could not. And I'm going to assume that it's the content of the app we're discussing, and not the app itself, since that's kind of trivial.

So, the question is, without a web presence or API of some type, how exactly is data expected to be searched and shared by third-party participants? If the argument is that apps don't solve the problem of having a universal ontology, then I think the GP is not quite understanding just how intractable a problem that has been in computer science for a very long time.

They're achievable, but not native. You can't make your content crawlable unless it's on the web. You can deep link and share, but only if you explicitly build all of that while it's native to the web. And another one that always annoys the hell out of me is that I can't search text on an app screen. Again, you could build it yourself, but very few apps actually do.

I don't understand why people think this is a huge friction point. Installing apps is comfortable, familiar, and easy for people. By comparison, finding a mobile web application in the browser on a phone has significantly more friction.

I might of not been clear, but my intent with the comment was to encompass the entirety of friction points involved in getting an app installed on a user's device, from discoverability on down.

True but there's additional friction on the web app side as well. At this exact moment without looking at my browser, I'm not sure how to add an app to the homescreen. How many users actually know how to do that implicitly?

A lot of people in the real world don't want to install apps.

Also I disbelieve on how hard it is to find a mobile web application on a phone. Find it once, save a shortcut to a web page on your home screen, and now it is as easy to launch as an app. I actually find this easier to do than it is to install an app.

> A lot of people in the real world don't want to install apps.

A lot of just a specific subset of highly technical people? I don't think I've met anyone with an aversion to apps who also used a ton of mobile web apps.

> save a shortcut to a web page on your home screen

How many people did you lose at this point?

- The study in the sibling reply shows 65% of users dont install any apps in a month. I would think technical people actually install more (for testing etc)!

- Actually you don't lose anyone because browser history and address bar autocomplete are your friends. I dont think people care to save a shortcut, because they know they will be able to find it later.

I'm a technical user and I haven't installed an app in a month. I've probably gone a few months without apps. I've used a few mobile websites and zero mobile web apps.

I don't think it's fair to say that users who aren't installing any apps are actually going to mobile web apps instead. They're simply using what they already have. At some point I have all the apps I ever need for all the interactions I use my phone for.

> Actually you don't lose anyone because browser history and address bar autocomplete are your friends.

On the desktop sure, you might have a point, but interacting with a mobile browser to find stuff that way is not a good use experience. You think browser history and autocomplete is a substitute for a home screen icon? I don't know how to respond to that.

> I don't understand why people think this is a huge friction point.

Because the numbers seems to indicate that. http://qz.com/253618/most-smartphone-users-download-zero-app...

Because when you're browsing the web on your phone and you come to a page and you get a giant banner that says "HEY INSTALL OUR APP" what do you do? If you're 90% of the world, you hit the close button on that banner.

That's right. And yet I still have 5-6 pages of apps on my phone. So I don't understand your point.

Pro-tip: You can make your article sound like it's been written by a grown-up if you find/replace all instances of the word "fucking" and "fuck" with "".

People also just speak differently. You're allowed to curse on the internet, and as someone who lives in Queens, I honestly have trouble speaking without cursing. It feels kind of stilted and overly proper. Language is fluid and evolves.

Fo-Realz...LOL

But presumably you don't write in every "um", <cough>, stutter and mis-speak so why keep in the swear words rather than cutting them and increasing your readability and information density? You may have trouble speaking without cursing but you clearly manage to write without including the curse words.

Sure, it may be cheaper to build an Android app and an iOS app than it is to build a responsive web app. I'll buy that.

But most customers want an Android app, an iOS app and a web site for desktop.

It's certainly cheaper to build that desktop webapp if you don't have to make it mobile-y, but is it cheaper to build an Android app, an iOS app and a desktop webapp than it is to build a responsive webapp?

'www' should stand for wild, wild, web. In many ways, the web is a technology frontier, with all the frustration and liberation that goes along with it.

I sympathize with the author. The problem is trying to tame the web, as opposed to embracing it for what it is.

It would appear that "what it is" is "not good enough", and that the sort of functionality and control over behaviour an layout is so hard to achieve on the browser that it's just not possible for any reasonably complex app and for a sensible price.

Seriously... there should be a framework that takes care of all that for you.

We built this framework. And it took us four YEARS. Ok, it also does a ton more stuff than just make the app work across devices.

But, the web rocks. Seriously. PhoneGap lets you basically stuff the web app into a fullscreen shell and go to town. And the best part is that you gey to control updates, totally legally without Apple holding you up. Have a front-end bug? Fix it for everyone tomorrow! Have a new feature you want to roll out to only 5% of your users? YOU CAN! And then A/B test it. Whoa. Like how would you A/B test with the app store? Yeah, that.

Also... when invitation links are clicked, where do you think the mobile user goes?

TO THE WEB.

And so... you need a web experience anyway, that does more than say "Please download our app. Here is a nice picture and description so you can clutter your phone now."

And finally... web push notifications? Yes, this is one of the TWO BIGGEST THINGS MISSING in iOS Safari. (The other is access to the address book, with permission of course.)

But I think that's about to change at WWDC. Android Chrome has Web Push!

"native app developers seems to think $50K is the smaller amount you should bill for a native app these day"

Ummm, yeah, I would say $50k would cover a small native app using Parse or similar or an extremely light backend. Even a medium size native app is going to run $100-150k. That's the price of software development if it's happening in the US.

One thing we tend to forget as developers is that in any industrial process, there needs to be technical limitations enforcing requirements before requirements enforce technical specifications. We tend to be too easy because everything seems achievable with software systems.

A project should start by considering political things such as: is it smart to have this particular application hosted in a marketplace. Right after that, the chief engineer should be consulted to know the technical approach (platform, stack, etc...) that should be used, and the technical limitations that the requirements should observe to allow the development effort to be successful and efficient.

The more self-imposed technical constraints are observed, the more successful and easy the development will be - and passed a certain point, the more difficult it becomes to sell the product or service.

Applying this reasoning to the article, to me the problem is the very thing they have decided to develop.

Responsive web apps are difficult to build, however settling for native Android and iOS is not sufficient for comparison since he's leaving out the desktop (so he should probably include Windows and OSX for some level of parity for what a responsive web app can do).

The real underlying problem is the state of the mobile web browser, which neither Apple nor Google have much incentive to improve due to their revenue generating app stores. That's not to say that there wouldn't still be some major differences between native apps and mobile web (especially in the discovery / delivery department), but if you had better feature parity between these platforms I think rants like this guys would be fewer and farther between.

tl;dr: He picked the wrong technology platform for his product, therefore since it didn't work for his use case, it must be fundamentally broken.

Mobile Chrome + Mobile Safari would be a great way to cover enough bases to make a good responsive web app reach a huge audience. The core problem is that Mobile Safari is really quite frustrating in a lot of ways.

As a simple example, I had a bug with some of the dialogs and menu popups I was using not rendering in Mobile Safari. It turns out that if you have a div that is a child (in the DOM) of a div that has overflow: hidden, that child will not be rendered outside of the clipping box of the parent, even if the child div is position: absolute and at a higher z-index than the parent. This works differently in chrome.

There are plenty of workarounds available, but the basic strategy of creating a position: relative context and having a position: absolute floating menu / dialog that's rendered near the button that creates it won't work if your menu bar has overflow: hidden on it. But then you have to make sure you've got your menubar set up well so that it doesn't become super-tall in narrow screens, because you specified overflow: visible. Or you have to put your floating divs elsewhere in the DOM tree and specify their position as fixed and manually calculate where to put them using javascript.

It's things like this that frustrate me the most in working with safari - I'm constantly wrestling with a rendering stack that doesn't seem to do what I want (it was only in recent versions that I could stop setting flex-basis: 0.01px instead of flex-basis: auto (on safari) like I do everywhere else on divs that had only text children that I wanted to make expand but also become multiline text instead of pushing everything way out to the right. And don't get me started on safari's support for indexeddb, let alone the other neat features that chrome is supporting to make mobile just plain better.

I'm at the point now where I'd literally be willing to tell my users: "install chrome for iOS" if it were actually chrome, instead of supporting safari. But instead, I deal with the sort of resonance back-and-forthing when I fix a safari layout bug that introduces oddities in chrome's renders.

>The web is the future. The web will always be the future. But that’s the problem. I need to ship products now.

It's like tomorrow is always tomorrow -- it is never today. One thing that bothers me about the web dev community is the insistence that technology has a will of it's own. As if the web will just eventually win no matter what. I consider myself an advocate for the Web but it needs to be good or better than the alternatives.

So, joke aside, it doesn't follow from the rant that the web is the future. It follows that there is a lot of work that needs to happen before you can say it might be part of the future.

I don't like the dramatic at all.

It allways has been the case, that if you used the most bleeding-edge features, you will bleed getting it to work everywhere. Very painful indeed, but I won't suspect, that this is going to change in the future, with so many people and companys involved.

So if you need to ship products now, you have to use, what's stable enough, if you want to target everyone.

The core of his argument really boils down to: I have to do it this way because my audience is 12 year olds and this is what they want. A good lesson in knowing your customer I guess. But I don't think the conclusion is useful for most people.

Another thing that stood out to me: "a closed ecosystem will always deliver higher quality in any given moment." Which is so absolute it's ridiculously easily disproved, even while being true at certain points.

I used publicly whine quite a lot in favor of open web standards. When the specs were simpler, this made more sense, but as they grew more and more complex I felt overwhelmed with the chore of developing cross-browser apps. The investment of time required just didn't make sense anymore, and I felt like the only way to serve the web was to develop simple content-focused pages, and leave any complex functionality to native apps.

"Do I miss IE6? As a CEO, actually yes." Seriously? Article should just have started with this, then I wouldn't have had to read the rest.

The web's view layer, html and css, has the wrong granularity for building precise ui. Html's controls are too high level for pixel perfect manipulation, and too low level for easy assembly into rich ui. CSS meanwhile tries to get you to make general rules that interact to produce a precise rendering, which you never quite achieve because there are always unintended side effects of the rules. No native view api works like this, and for good reason. Since these technologies are almost entirely but not quite unsuitable for building a native-like view layer, people build abstractions around them to approximate the view layer api any native ui gives you. But then the problem becomes one of synchronizing the facade view to the real view, hence ten thousand templating and layout frameworks, all while continually dealing with the leaky nature of the abstraction.

I guess what i'm saying is that i believe in the principles of the web, but i think html and css are terrible technologies that do a disservice to those principles.

> Html's controls are too high level for pixel perfect manipulation, and too low level for easy assembly into rich ui.

HTML+CSS isn't the only abstraction available, though. If you want a lower-level abstraction, you can use canvas. If you want a higher-level abstraction, you have your choice of composable view component systems (e.g. React).

Problem is no one wants to download your native app.

Agree with everything except with the numbers. Users won't install your app that much so it goes to a balance. It depends of course on the application itself but, since you're struggling so hard to go 'web', I presume it might be a mobile version of a website. I visit a lot of websites each day but do I install everything those websites suggest? No!

I'd say it again: break compatibility and make an open, preparsed/compiled/binary HTML format. You'll get several order of magnitude speed increase and reduced memory consumption in browsers (parsing text is expensive). Something a little similar to microsoft .CHM file format.

So instead of having a competition in browsers, you'll have competition is the HTML parsers that developers will use.

No more messy W3C messy standard which is VERY hard and ambiguous to parse for any browser.

I've repeated that rant so often, I might start making a simple example of what I'm talking about. We just MUST abandon the text only approach. It allowed the internet to thrive without microsoft's attempt to make money with it. But today browsers are so ubiquitous, all that there is to do is enable browsers to just render binary HTML, which would just be a tree of rectangles and styles, so really simple. I think.

Aren't the big bottlenecks things like waiting for large resources (images) to download and javascript processing? The parsing of HTML, as far as I'm aware, has a tiny relative impact.

> javascript processing?

Actually Javascript engines are extremely fast, the UI in a web app isn't because web engines have to deal with a complex repaint model. Resources can be loaded asynchronously, so it's not really a bottleneck. On the other hand repaints can absolutely be a serious bottleneck in webpage.

Native UI use a much much more simple model, which makes repaints less expensive and allow a better FPS rate.

That's why webpages shouldn't try to look like native apps on mobile.

If we had started with a binary HTML format to start with, many of the progressive enhancements that made the web possible could not have happened.

Maybe. But maybe those progressive enhancements are not good ideas either. HTML just enabled to penetrate the microsoft platform. HTML was designed for static documents, not web apps.

So argument isn't so much that we should have binary HTML but we should actually just run Java* apps in a sandbox. I'd say there is merit to that argument and we'll probably get there the long way around. Perhaps webassembly will succeed where Java applets failed.

* Or your virtual platform of choice.

Sandboxed apps are not really a good thing IMO. I agree that webassembly is a good thing too.

BUT, my critic is about the DOM and the text-only approach, and also HTML not being strict enough so that all browsers can use it. It is the same compromise between having a compiled or an interpreted language. A compiled language will always be faster and smaller. If you put the burden on a HTML compiler instead of how the browser displays a binary document, you won't have those issues.

> Sandboxed apps are not really a good thing IMO.

Interesting because isn't that sort of what you advocating for. Ultimately what's the difference between strict compiled binary executable "HTML" and something like a Java applet?

> BUT, my critic is about the DOM and the text-only approach, and also HTML not being strict enough so that all browsers can use it.

But really the problem isn't the syntax of HTML/CSS/JS but the semantics. Everybody can parse this stuff pretty much equivalently now but they still do different things with it. I don't see how compiling to binary would change that.

Binary html is not an executable nor a program, it is just data, here it would be the dom tree, compiled, not using text data all over.

> I don't see how compiling to binary would change that.

The solution is forcing a stricter version of the language. https://www.youtube.com/watch?v=Q4dYwEyjZcY

Two issues: the problem is semantics not syntax. A binary version of HTML with all the same values a text version of HTML won't change anything. It isn't the values, it's what done with the values. This is a fix to a problem that doesn't exist.

A stricter version of HTML would not have allowed for the progressive enhancement that existed throughout the evolution of HTML.

VERY relevant article: https://govinsider.asia/smart-gov/why-britain-banned-mobile-...

Ben Terrett was former head of design at the UK Government Digital Service and he wholehearted disagrees.

It's refreshing to hear so much competence from a part of a government ...

But about the disagreement: government-apps don't need to be bleeding-edge, like the one from the article. They just have to work without glamour. So 2007 works fine for them ...

The author of the article ignores user experience: it is much nicer to use a web app than install yet another app. Personally I don't like installing web apps, even if they don't ask for a lot of permissions. Also re: notifications: I think most users don't like to be interupted by notifications.

User experience is generally much better in native apps than in websites, though. Native apps match the look and feel of the native platform, with all of the network and performance benefits that entails. Native apps can integrate with the platform to a degree that web apps just can't.

On the other side, I prefer apps and use them almost all the time. And I like notifications very much. I can disable those I don't need and instant notifications of important things are very handy.

How about a real world example.

tl;dr The Hybrid app took longer to ship (+ 20%), and was more expensive (+ 525%)

We were able to participate in a unique experiment: - Develop a native app for iOS and Android at the same time a separate team was developing the exact same app as Hybrid (Cordova/React).

The app had 20 screens and used modern UX (onboarding, profiles, hamburger menus, alerts, GPS, content rich screens (text/images/video) with lists/details talking to a backend REST API with local/offline/sync'd storage.

Native = 8 man/weeks

- 1 iOS dev for 4 weeks - 1 Android dev for 4 weeks

Hybrid = 50 man/weeks

- 5 Hybrid devs 10 weeks

You can argue that the 5 devs had overhead in communication and project management, but we observed that was not a major contributing factor.

The above was for app development (not the server). Hybrid app required the same amount of QA as the Native app.

I built this app with web tech. It was sweaty, and I many times wished that I had gone native. But now that it's done it is something native could never be :) http://www.oneviewcalendar.com

>But it pisses me off every time I see a Twitter thread about how native apps are destroying the free world.

I can't understand this sentiment the author claims to see. Web apps are generally going to be less free than native apps. A native app doesn't have to be open and a web app doesn't have to be open, but a web app is definitely going to require that you connect to the host, will probably keep all your data stored away from your grasp on its servers, and may change its functionality and terms of service at any time. Native apps can share many or all of these traits but at least there's a chance you can control a copy of the software. The web is a terrible software platform for users.

I freaking love the web as an app platform. Now I don't have to wait for Google Maps for Linux, or Gmail for Linux, or whatever. That world sucked.

Google Maps is magical, but it isn't magical when you can't view uncached tiles or search for things when your connection is offline. A downloadable map application that you could purchase and view and search entirely offline would be even more magical.

Seeing as how Open Street Map's complete dataset is 40 GB compressed (and that probably doesn't have all the businesses, addresses, keywords, etc. of Google Maps), there's a pretty good reason why you can't search it offline. Not to mention, why would Google give away all their data on every install.

But, you are partially in luck. Google Maps now allows you to download up to 120,000 sq. km. https://support.google.com/maps/answer/6291838?hl=en

> How many of our web evangelist are using an Apple laptop, the most closed ecosystem around?

He's got a point here. I gave up my MBPs for a Win 10/Linux notebook, and I've come across some opensource and commercial projects I hadn't noticed only worked on OS X and Windows (MAX/MSP). Sometimes Linux is supported, but as a third, less-supported option (Mathematica 10.4).

Maybe it's because I made the change that I am focused on this now, but every talk I watch has the Apple logo.

I've noticed some older coders with cred are rocking Lenovos and 3 to 5 year old laptops. I used keep a laptop for 4 or more years, but now I am guilty of 'upgrading' every 2 to 3 years.

If you miss Ted Dziuba's writing at Unvoc you will thoroughly enjoy this article

I completely agree with the article. I joined a startup a few years ago and we went mostly native on Android and iOS with some simple screens as web views shared between them. Later on some clients wanted desktop and Windows Phone versions so we built a lesser featured version as a website to cater for any other devices (adding features as necessary). We started out as 3 software developers and a designer and are expanding. Native apps was a more cost effective way to deliver a good experience while the competition mostly developed web apps resulting in a lesser experience in my opinion.

Good luck having the users download your app. I use everything from the browser, including gmail and twitter (both load faster and don't bother me with notifications). However I hate how they prompt me to download the native apps every fucking time (obligatory). I actually wonder, what are the action rates for those app install prompts?

If you don't play games there is barely a reason to download an app ever.

And really how bad or difficult is the mobile web? Use bootstrap and you have a pretty fine experience. I think we are focusing too much on slick experience instead of offering something useful.

You should still STRONGLY PREFER Web Apps. The cost and headaches of a web app will be MUCH LOWER than native or even hybrid app development.

BUT, if you need a Native App, make a Native App and don't try to fake it on Web.

Really excessive and sometimes completely out of the road: "Open standards are always going to be inferior to closed ones. How many of our web evangelist are using an Apple laptop, the most closed ecosystem around?" You have many open standards that are superior to closed ones, simply because it unleashes creativity of the community. Many techies use Apple because they build an amazing user experience, based on a closed but very large ecosystem - go to the App Store and you'll see most of the apps you need

Is there some rule that startup CEOs have to say "fuck" a lot?

I can sense the frustration, but I don't think it's the web's problem necessarily, and I've done work in both areas. Some ideas just don't work well in a web browser, because despite 20 years of attempts to force it down that path, a web browser isn't the same as something like Flash, let alone a native software stack. There are more stakeholders than just the app development people, and they don't always care about the same things you do.

We do the same - each of our Android and iOS developers can complete a medium complexity app in 2 months flat without any issues - Web - not so much - while initial work is done much faster - it takes ages to tackle responsiveness issues even with Bootstrap. So although our web apps are responsive - we still provide native Android and iOS apps to clients. I don't see web apps replacing native apps anytime soon.

A lot of the issues here are with mobile Safari. I agree it completely sucks just due to how behind Safari are with ES6. On the upside the work is complete to fix this in dev releases, so there's a very good chance that we're 3 months or so away from a large step change. I'm not planning on releasing anything in the next 3 months, so that timetable is okay for me, YMMV

I don't think that it's ES6 that's holding them back, there's Babel to fix that, I think it's all the browser vendors and the varying level of standards, different bugs and behaviors on every browser platform, plus there's features on Native platforms that are nearly impossible to replicate on the web. For instance `backdrop-filter`/iOS 7 like blurring wasn't possible on the web until Webkit implemented it, a year later only Safari has it and it's buggy in Chrome Canary (it blurs content under the box shadow). Another example ServiceWorkers, only in Firefox and Chrome, which cover most users on the Desktop, but on mobile you're screwed because half of your users use mobile Safari.

And for good reason. I don't want random websites burning my battery for their "oh so important" background tasks.

This seems like a misunderstanding of the tech. Service workers can really only fire up when they get a push notification, which you have to explicitly opt into, or when the page is running in the browser.

The processing allowed is tightly controlled, and even with permission the push notification can't do anything behind your back - it has to result in a visible notification which will alert you that there's something you want to disable.

backdrop-filter tends to go in my not-very-nice-to-have bucket. It's certainly something you can live fairly comfortably without.

Service workers are more of an issue - realistically if you want to build a serious web-app for iPhone right now you're going to have to build a shim around it for notifications and offline, although that can be quite small.

If you are aiming to provide a worthwhile experience to the users who will never install your app, or need some serious selling first then you need something on the web, so you are going to have a mobile site. Building a lightweight service-worker shim around that for iPhone and providing a couple of browser-specific stylesheets ought to be less work than full native apps.

I filed the backdrop-filter bug: http://crbug.com/618913 Hopefully we can get it sorted. :)

Last time I checked, a lot of Android phones in my region (including new ones) were running 2.X versions with some unnamed browsers (probably webkit-based, but not chrome). For me that's much more issue. I can live with Safari, because there are 2 actual versions (iOS 8 & iOS 9) and they are modern enough. But those archaic androids with unnamed browsers are nightmare that I have to support.

I understand and empathize with the author's aggravation. But cheaper? Really?

So iOs and Android are more than 90% of the market. You are telling me that it is cheaper to build and maintain 2 separate apps and pass on the remaining part of the market than have one app that covers everything?

Android device support is supposed to be a nightmare - there are so many versions to contend with, each device manufacturer can customize things.

iOS is easier to support but fighting with Apple can be quite the ordeal.

Using the web means you bypass these other issues but have to contend with the ones cited in the article. It sounds like pick your poison.

I could conceive that after the initial cost of building 2 separate apps, for iOS and Android, that perhaps it is less aggravating and costly to maintain them, as opposed to dealing with the web. However how complicated is the UI for the web apps? Can't you keep it simple? Unless you can show numbers I cannot in my wildest dreams believe that building and maintain 1 web app is more than twice the cost of building and maintaining 2 separate native apps.

What are you building that requires building a 2016 Web app with every new feature? Maybe that is your problem.

Using the web means you bypass these other issues

Not really. If you are doing anything that relies on device hardware, camera, microphone etc... then device type absolutely matters - and it's even worse on mobile web because you can't get close to the metal.

I would agree, the native interface with hardware would be easier with native than the web. But the testing issues across all android devices is still an issue that the web should not have to contend with. And the Apple store issue is hard to quantify. You just don't know if they are going to let you in. The web means you don't have to get the user to install the app.

Of course if you use cordova or phone gap you still have to do deal with those issues. I still cannot conceive when 2 separate apps are cheaper to maintain than one.

  > You just don't know if they are going to let you in.

You do know.

You won't know until AFTER you apply. You'll find out after. There are numerous HN posts where founders have submitted their app to Apple and have been forced to wait or resubmit.

I can only shake my head at the venom being reserved for this post.

"But the testing issues across all android devices is still an issue that the web should not have to contend with."

And yet, it is.

"And the Apple store issue is hard to quantify. You just don't know if they are going to let you in."

Yeah, you do. It's pretty easy to read the rules. And things being flat out denied, rather than told they need to fix something, is really rare.

The number of permutations for testing scenarios across android versions as well as hardware manufacturers is significantly bigger than the number of available browsers. The difference between browsers is well documented and as far as I'm concerned finite. How many versions of Android are worth supporting? What about the differences between manufacturers. Browser differences are generally known and well documented. Can you say the same for Android?

There are many scenarios where I agree it is significantly harder to create a user experience building a web app that can compare with the native experience. But the premise of the article is that it is cheaper to build on 2 separate native platforms than it is to build web app?

The part that gets me is the author complains about things like multiple line ellipses and autocomplete text boxes. Here's a better question - why are multiple line ellipses core to your business? What value does a multiple line ellipse do for the app?

Wow so this post has been 'reported' already? The hacker news justice squad is swift.

> So iOs and Android are more than 90% of the market.

98.4% http://www.gartner.com/newsroom/id/3215217

I think it's pretty reasonable to pass on the remaining 1.6%, especially as those probably aren't your target audience anyway.

The 90% was based on a previous post. I was too lazy to search for the total market share of iOS + Android.

If you're building a web app (of more than trivial complexity, where you need to do things like profile for performance or access the user's hardware), you are building four apps: Chrome, IE, Firefox, and Safari. I mean, there are other browsers, but let's not kid ourselves. ;)

You are, in fact, also building those four apps on five different architectures: Android, Windows, Mac, Linux, and iOS. There are others, but again, let's not kid ourselves.

Your complexity surface is the product of your feature-set, the quirks of each of those browsers as they silently version-up for your users, and the quirks of each of those browsers on each OS platform as they also vary in version.

If you're building a trivial web app, it's a web page and by all means build it directly in the browser. But when you start to bust out the profiler to figure out why this one interaction is butter-smooth in Chrome and runs like crap in Firefox from versions X to Y, except on Linux where it's X to Z... Two mobile platforms is fewer than 4 browser platforms.

I forgot why I stopped posting on HN for a while. And then with this post I remembered. Thanks for reminding me.

It might be true that it's a pain in the ass to write a responsive web app, but that doesn't mean it's not worth it. Users are unlikely to download a mobile app just because you say so.

Of course YMMV. If you have control over what the user does like some kind of internal enterprise app then go for it.

I wonder if multiple native app is still cheaper than maintaining multiple different web builds.

Reminds me of this library I stumbled across.

http://www.zebkit.com/

People either respond with this is cool or your going against the web when I told them about it.

Have a look at Delphi if you want cross platform native apps https://www.embarcadero.com/products/delphi. It's very easy, $50K would take you a very long way.

Key takeaway: "Open standards are always going to be inferior to closed ones." This is totally true, but as the author notes, open standards still have their place.

Also, I realize he's mad, but he really needs to expand his expletive vocabulary :)

Since the article doesn't touch on specific I'm wondering where React Native falls regarding all this. I'm considering using it for our pending iOS and Android apps, seems like a no-brainer at this point versus true native.

Well React Native is one of many strategies they could use to build their app and later on back port their components to the web, should they resurrect it. I would agree with your point that it's a no brainer.

At age 38 I'm a little bit of an oldster for this industry, and I remember PCs in the 80s. I was a kid but that's when I learned to code and I distinctly remember what it was like.

It was a lot like today: loads of fragmentation and loads of vertical 'silos' with their own peculiar way of doing things.

Until the late 1980s you had a million little vertically integrated platforms: Apple II, TRS-80, Commodore 64, TI-99, IBM PC, etc. Even within manufacturers you had major incompatibilities, like Commodore VIC-20 vs. Commodore 64. Those were almost totally different machines.

Then the explosion of cheap IBM PC/AT clones changed all that and killed all the smaller players. There was a brief period from about 1988 until roughly 1999 when we had essentially one platform MS/Intel. That was MS-DOS and Windows, and the latter would usually run DOS apps. You also had one UI metaphor: the mouse and the keyboard and the screen. You had some hardware fragmentation but if you were targeting OS APIs and not trying to be bare metal it wasn't too hard to deal with. You mostly had one platform you could target and get 90%+ of the end-user market.

No more. Today if you want that 90th percentile of the user base you have to roll at least three completely different UIs at a minimum. Either that or you go all-web, which as this author correctly points out is a major headache if you want something that's mobile friendly. We've had good luck with bootstrap+react but it is more work than targeting a single native platform. (Not sure if I buy that many native platforms are more work... probably depends on the stack.)

On one hand all this diversity is interesting, but on the other hand if you just want to ship a damn product it's infuriating. It's also true on the backend: you have at least six Linux distributions, Docker, a million different 'stacks', clouds like Amazon building closed mainframe platforms like lambda, etc.

"Building" is very small part of software life cycle.

Is it also cheaper to bug fix, add features to, update apps when each native platform updates, hire developers who know details of each platform, etc.

I'll disagree and say its cheaper, faster, and less risk to bug fix and add features if you only maintain one codebase.

Well then you are agreeing with me, because that is what I said. One webapp cheaper, faster and less risk than multiple native apps.

This person is angry. I can't imagine that if someone was ridiculing me on Twitter for destroying the free internet I'd care enough to start swearing up a storm.

My current employer bought the app I work on from my previous employer. It embeds websites in webviews with JS-Objective-C/JS-Java bridges so they can make native calls. You get most if not all the benefits of native apps, native UI when you really want it, quicker iteration then the App Store, and can build in whatever stack you want. Of course I've had to follow an intermittent bug from the rails back end, to the angular front end, to the native java and up to the companies api servers before, so YMMV.

No it's not. Get better designers - ones who understand responsive design, and developers who speak modern javascript.

I'd argue that "modern JavaScript" is a pretty huge part of the issue at hand.

I think it's interesting to know that native apps need to be responsive as well.

Has he looked at mixed tech like React? Get web tech with native controls!

React is absolutely not going to make things easier for him.

The requirement logic of my benefactors necessitated no less...

Well, I'll take all of that instead of the fg cp the native gives me from all the bright minds at ge, ae and mt, anytime. The future is here.

Makes sense and reminds me of 2006-2007 when this was a big topic in the US with Android and Windows mobile apps with Apple in the passenger seat

You're clearly doing it wrong...

But which is easier to maintain?

you're wrong. dead wrong. about 2012 was the turning point in this game...

What this article needs is more F-bombs. Otherwise it's ranty but makes some good points.

I like the last line

Makes sense

I don't think "web apps" are as problematic today than they were several years ago. I don't say this because I hope web apps will be the future of app development, but because together with a few other devs we have built such an app at the company I work for. I think the result is a success but unfortunately I didn’t have enough time to write about our experience yet. I hope I will have the time to so anytime soon.

Yes the development costs are super important, especially for small companies / startups. As important is the performance of your app(s) and also super important is the usability of such an app. If the development costs are much higher than building native apps besides your website, then you failed. If your app is slow and unresponsive then you failed. If your users dislike the app because it is not smooth like a native app and feels sluggish then you failed.

But does this mean that building mobile web apps is impossible, I don’t think so. We did several things that helped us to keep the costs as low as possible and for sure much lower than if we would have written server, apps and client code using different languages / frameworks and libraries.

Our server side code, the code of our web apps as well as (obviously) our client (browser) code are written in javascript. We have used typescript to write all our code, this allowed us to use the latest ES6 features and gave us features like strict typing. The ES6 features we have most used are promises and classes. Typescript compiles our ES6 code into ES5 UMD modules. We choosed Visual Studio as IDE as it compiles typescript on the fly, which allowed as to quickly test new code almost in real time. We also used the node js tools for visual studio which allowed us to use the node js debugger from within our IDE. Setting breakpoints (typescript creates Javascript to TypeScript source maps), reading stack traces or watching variables was a piece of cake.

We have built an isomorphic website first. Our server side got built on top of express js (node js). All our modules and libraries are UMD modules, which means that more than 95% of the code we wrote is the same that we use on the server and in the client. We have built a server views renderer using Backbone and domino. Our collections and models are the same on the server and in the client, the only difference are the adapters we wrote to make ajax or server side requests. We use the same router on the server and in the client, which means the first page that gets served is always built on the server but the next pages are built in the client. This also means that crawlers can harvest our pages but for users we only retrieve the data needed to build the pages from server and do all other work in the client, which makes the pages load very quickly. We also had to write a cache library once, the only difference again are their adapters, the server adapter of our caching library saves objects into redis while our client adapter saves them in IndexedDB. A lot of things needed to built the pages get cached too, so each template, each translation and so on only needs to get fetched once by the client and can be reused until we publish an updated version of the item.

Our web apps are built using phonegap. Again 95% of the code of our apps is the same as the code that is being used by the client (browsers). Obviously we had to write clean and powerful code to ensure that our apps come as close as possible to the speed that people expect from a native app. We had to track every minor memory leak, especially those that occur when binding events to ensure that our apps use a minimum of memory. This was not only important for the web apps but also for the node js code. A memory leak is something you really don’t want to have when writing a nodejs app ;).

I think what helped us to keep the costs low, was that we used the same language and therefore resulting code for the client, server and apps. But this did not only allow us to work quickly, it will also allow us to add new features quickly in the future. If we now write a new feature, as soon as we release it, it will be available to users that use our website as well as users that are using our Android / iOS apps either on their phone or tablet. The same is true for bugs, if we find a bug in the client and fix it, it will be fixed for all our platforms.

The other big advantage was that all the know-how we had but especially the one we acquired during the time we needed to build our project did benefit all our platforms. We didn’t have to optimize our Java code for Android our Objective-C or Swift code for iOS and our PHP, Ruby or .Net code for the server. We just needed to optimize our Javascript code. We reduced the amount of platform / language specific problems to a minimum. It is really great when all your devs use (speak) the same language ;).

No.

Although a rant, this is also pretty substantive. We've replaced the baity title with a representative sentence from the article in the hope that commenters will follow suit.

The fact that you go to this effort is why I love HN.

If only we could get notifications for replies & a decent mobile app existed.

I just check a couple times a day... honestly, I'm usually too busy when I'm not checking HN to deal with a reply right at any given moment anyway. It's a forum.

As do I, but the conversations I have on HN are more fascinating to me, so I'd actually rather have push-notifications on HN than Reddit.

The biggest thing is still a better way to browse/post on iOS.

Dunno, I'd be okay with web notifications via chrome.

Though that some clickbait sites are asking for that permission is really irritating... I mean more so than interstitial or late-loading ads that push content down.

I use hnnotify to tell me about replies and the Hacker News app on iOS by premii is pretty decent for read only access ( I mostly only post when I'm at a computer, I find that my responses make a little more sense that way :) )

Kind of wish HN would adapt Open* or similar for token access for posting... though that opens the door to a lot of potential issues (spam) I'm guessing they're trying to avoid... maybe requiring the web interface until you hit 1K karma or something.

Worrying about spam doesn't make much sense here, as the web interface is pure HTML forms, with no client-side checks. It isn't hard to automate the posting process.

Yeah, I found several decent read-only apps, but that hampers the experience for me.

Did you read the blog post? It would need to be at least two decent mobile apps.

Dan Grossman maintains a tool to help you with one:

http://www.hnreplies.com

I use it.

Nice.

I still wonder why HN seems hesitant to develop the HN platform further (although I'm relatively new to the site, so I don't know the history).

I use minihack on iOS, it works quite well for reading and posting. UX is a little under designed, but it does its job

"Top 10 Sumome popups you won't believe your eyes when you see" didn't cut it for you? Thanks for making our day a little better!

Substantive but not new and something that could have been said in much fewer words. If the baity title had been left alone I would have been saved a waste of time.

He forgot to mention how web frameworks come and go, and then you've got this legacy code nightmare. Also breaking upgrades and dependency hell. I'm a front end web developer, and yeah. If your building something simple, the web is the way to go, but his complaints are totally on spot.

Yup. I've got iOS native code written for iOS 2 still runs like a champ. My 2 year old angular 1 code is looking like a total rewrite.

Consider the following problem. If this very question is relevant, then your project is not.

Would it have mattered what they had picked for Google Search? A web site or an app? No. It would not have made any difference.

If what you are building is compelling to its users, they will want it badly. Otherwise, regardless of how well you package it, it will be a waste of time.

You see, for example, companies choose SAP, and then they buy the servers, desktops, and other hardware and software that is suitable for running in a SAP context.

Nobody cares whether the SAP client is a desktop GUI or a web client. It is immaterial. In other words, if that kind of things matter, your program doesn't.

at first I rolled my eyes but by the end I was filled with sympathy and agreement! spot on!

if web is future then future is now!

1 dev = all 5 device dev = 5 apps

1 dev 100k 1*5 500k in salaries

I guess he hasn't heard of React Native...

React Native is no panacea. For example, Discord has found it unsuitable for Android so far. [1]

https://discord.engineering/using-react-native-one-year-late...

They tried it for Android at the "early stages". It may be better now ?

What about developing a core codebase to build an app for different platforms (including the web)? There are framework out there that can help you do that. At least in C++ (this is the language I use the most).

And if only there were solutions that made it easier to prototype and get your backend running faster. It could make it even cheaper to make native apps. end: self serving response :)

Hawking your own startup here doesn't make sense since the issues presented in the rant discuss user-facing product architecture.

It was done tongue and cheek. Sounds like that's frowned upon. Heard and heard.

Reply on news.ycombinator.com