3 ms·

Disagree with a few things, the title 'static is better', is hyperbole, its a different environment. Also the 'the doesnt mean they are any less capable' is pre

Disagree with a few things, the title 'static is better', is hyperbole, its a different environment. Also the 'the doesnt mean they are any less capable' is pretty much by definition wrong. That being said I absolutely love the architecture, pretty much every application I build these days starts with switching my github default branch to gh-pages. I work on http://pouchdb.com http://pouchdb.com and use that for storing and syncing data. not having to worry about how my servers are configured / how they are running, how to move an application makes me feel like I can build what I want then when I come back in 2 years it 'just works', with dynamic applications I always feel there is a maintenance burden that I cant shake.

e12e 13y ago
> Disagree with a few things, the title 'static is better', is hyperbole, its a different environment. This. I feel I might fall under the hn banhammer soon, but I really wish people would actually read Fieldings thesis (introducing REST) -- it's a really good overview of the different architectures one might use for a client-server system. It' not just REST, REST is a natural conclusion drawn from the alternatives when the goal is a highly performing system for hypermedia: https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_2 https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch... But it's worth noting that fat-client styles are also in there, and the trade-offs mentioned are worth keeping in mind (no, there is no silver bullet -- you actually should choose an architecture that fits your problem domain. Shocking, isn't it?).