Live data from Hacker News

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

hueniverse.com

311–320 of 322 posts

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

#311
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.

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

#312

Earlier quoted context omitted.

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).

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

#313

Earlier quoted context omitted.

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 t…

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.

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

#314

Earlier quoted context omitted.

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!

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

#315
post #165

Earlier quoted context omitted.

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 firs…

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.

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

#316
post #283

Earlier quoted context omitted.

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…

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

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

#317

"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.

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

#318
post #291

Earlier quoted context omitted.

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…

> 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 bu…

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

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

#319

Earlier quoted context omitted.

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.

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

#320
post #318

Earlier quoted context omitted.

> 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 bu…

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.

Post reply on HN