I agree with this wholeheartedly…I was just having this discussion with my boss yesterday. I do not understand (mostly) this drive to push stateless frameworks (client or server). Obviously your framework needs to support stateless as to not waste resources, but almost every application I write is complex enough that without servers side state, I’d spend more time trying to figure out how to store state.
It’s one of the things I loved about Apple’s WebObjects and one of the reasons I’ve moved to Wicket over other more “popular” java frameworks. -Lon On Wed, Oct 11, 2017 at 3:35 AM, Andrea Del Bene <an.delb...@gmail.com> wrote: > Obviously I 101% agree :-). In addition to security issue I usually have to > struggle against the "big lie" of modern front-end libs which is "if you > follow us your application can be stateless". Non-trivial applications are > never stateless. If you have some sort of login mechanism you application > must handle a state somewhere! I've always seen these "modern" js > applications suffering of performance issues because they have > unconsciously moved state to database and they end up over-stressing it > because they want the application level to be "stateless". That's pure > madness to me!
