Hacker News new | past | comments | ask | show | jobs | submit login

Not too sure about this. With the explosion of ajax websites and mobile apps the burden has been put on the client. This means less memory.

It's very odd because as far as mobile is concerned, history is repeating itself. You have local apps running code. You can't assume those people running the app have as much memory as you. To build the best working app, run it on a smartphone with horrible specs. If it runs clean there, it will run clean most anywhere.

On the ajax website side it's the same thing. You're pushing the code execution off on the user. You have to be crafty about not assuming anything about the client.

A recent example I encountered was a "suggest as you type" feature for a website. If you try to lookup suggestions everytime a user types a letter in a search it will fail horribly on machines that are even slightly old. However on newer machines it works like a champ. So should we just not worry about those older machines?

Even the recent local sql db stuff (Web SQL DB) for HTML5 is an attempt to solve memory efficiency with current trends of pushing code execution to the client. Desktops (and most smartphones) now can handle large amounts of data, but the older models of ram storage via javascript arrays etc are not the way to maximize this. The local SQL storage stuff solves this issue by using the ROM.

Really this could have been done from the start (and was with cookies on some level), but necessity is the mother of invention.

No dev has a "love" of being trapped by constraints, but learns to utilize those constraints in the best way possible so when better things come along they can go above and beyond.

A real world example would be someone who learns to efficiently use memory can push off audio/video/image editing processes to the client side, while someone who relies on an abundant amount of memory could only push off maybe a few statistic calculations to the client side.

If you're looking for a business benefit to this: Pushing code execution off on the client without interrupting the user experience saves money on servers when dealing with scalability. Cut the processing in half by putting 50% of processing off on the client side and you cut your server cost in half.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: