7 ms·

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 tim

by donatj 10y ago

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.

rimantas 10y ago
And simple apps are absolutely trivial to build native.
elliotec 10y ago
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.
- deleted 10y ago
  [deleted]
rsp1984 10y ago
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.
- brianwawok 10y ago
  12 year olds don't have money, I would wait till people are at least 16 to care if they use my app...
  - RGamma 10y ago
    The toy industry would like to disagree!
    - deleted 10y ago
      [deleted]
  - deleted 10y ago
    [deleted]
  - brbsix 10y ago
    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-generated-more-than-2-billion-of-gaming-revenue-in-2013/ http://digitalkidssummit.com/2014/10/01/kids-6-12-in-the-us-...
- knieveltech 10y ago
  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.
- erikpukinskis 10y ago
  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.
tracker1 10y ago
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.
- elliotec 10y ago
  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.
  - tracker1 10y ago
    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.
    - ehnto 10y ago
      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.
      - tracker1 10y ago
        I think the benefit of using webpack/browserify for bundling modules and writing modular code is pretty compelling...
        10y ago
benmanns 10y ago
What would you consider the web of a couple years ago/solid simple guaranteed tech?
- elliotec 10y ago
  Rails and jQuery. I've had so much success with those technologies, it makes me weep to watch the HN crowd shun them.
codinghorror 10y ago
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.
- deleted 10y ago
  [deleted]
jonahx 10y ago
It's YAGNI. YNGNI is unpronounceable.
- groovy2shoes 10y ago
  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.
grok2 10y ago
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.
graycat 10y ago
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.
- 10y ago
alkonaut 10y ago
> 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.

by donatj 10y ago

rimantas 10y ago

And simple apps are absolutely trivial to build native.

elliotec 10y ago

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.

deleted 10y ago
[deleted]

rsp1984 10y ago

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.

brianwawok 10y ago
12 year olds don't have money, I would wait till people are at least 16 to care if they use my app...
- RGamma 10y ago
  The toy industry would like to disagree!
  - deleted 10y ago
    [deleted]
- deleted 10y ago
  [deleted]
- brbsix 10y ago
  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-generated-more-than-2-billion-of-gaming-revenue-in-2013/ http://digitalkidssummit.com/2014/10/01/kids-6-12-in-the-us-...
knieveltech 10y ago
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.
erikpukinskis 10y ago
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.

tracker1 10y ago

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.

elliotec 10y ago
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.
- tracker1 10y ago
  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.
  - ehnto 10y ago
    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.
    - tracker1 10y ago
      I think the benefit of using webpack/browserify for bundling modules and writing modular code is pretty compelling...
      - 10y ago

benmanns 10y ago

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

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

codinghorror 10y ago

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.

deleted 10y ago
[deleted]

jonahx 10y ago

It's YAGNI. YNGNI is unpronounceable.

groovy2shoes 10y ago
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.

grok2 10y ago

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.

graycat 10y ago

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.

10y ago

alkonaut 10y ago

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