Live data from Hacker News

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

hueniverse.com

321–322 of 322 posts

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

#321
post #220
post #66

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

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.

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

#322
post #283

Earlier quoted context omitted.

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

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.

Post reply on HN