nitter
Stefan Tilkov
@stilkov
13 Mar 2015
Before looking at JS MVC, learn how to build Web apps with server-side HTML; next, make them pretty with CSS; finally, add optional JS.
10
78
1
69
@dtanzer@social.devteams.at
@dtanzer
13 Mar 2015
@stilkov
wait, no. Server side is often a totally different use case. Sometimes a viable one. But not first/then. Cc
@bitboss
1
Stefan Tilkov
@stilkov
13 Mar 2015
Replying to
@dtanzer
@dtanzer
@bitboss
Frankly, I can’t imagine anyone is qualified to build a client-side MVC JS app who doesn’t know how to do it server-side
Mar 13, 2015 · 8:56 PM UTC
6
2
2
@dtanzer@social.devteams.at
@dtanzer
13 Mar 2015
Replying to
@stilkov
@stilkov
@bitboss
one is a rich client, the other is not. Both with all the advantages and disadvantages.
@dtanzer@social.devteams.at
@dtanzer
13 Mar 2015
Replying to
@stilkov
@stilkov
@bitboss
Rich client lets you completely decouple the presentation (browser) from the data (server, just an api).
1
@dtanzer@social.devteams.at
@dtanzer
13 Mar 2015
Replying to
@stilkov
@stilkov
@bitboss
Also, there're some things you cannot do on the server (offline capabilities).
1
@dtanzer@social.devteams.at
@dtanzer
13 Mar 2015
Replying to
@stilkov
@stilkov
@bitboss
Others (ajax, auto complete, ...) are hard w/o server side view state, which - IMHO - is an antipattern.
@dtanzer@social.devteams.at
@dtanzer
13 Mar 2015
Replying to
@stilkov
@stilkov
@bitboss
Although some frameworks handle server side view state better than others. I.e. wicket (good) vs JSF (bad).
@dtanzer@social.devteams.at
@dtanzer
14 Mar 2015
Replying to
@stilkov
@stilkov
Frankly, I can’t imagine anyone is qualified to build a Java app who doesn’t know how to do it in C ;) cc
@bitboss
@johanneslink
1