5 ms·
> but I think many will avoid using those features until they are commonly available client side too Why would you do that? If you have a few more advanced fe
by efuquen 13y ago
> but I think many will avoid using those features until they are commonly available client side too
Why would you do that? If you have a few more advanced features on the server side that doesn't run on the client why wouldn't a team take advantage of them just for server-side code. Maybe the fear is server-side code ends up getting run on the client, but I feel like the separation would be pretty obvious that should be easy to avoid. Node.js allows you use the same language on the frontend and backend but it's not like people are justing moving code around between the two without regard for what context it's running in.
- vertex-four 13y agoActually, there's a couple of up-and-coming node.js frameworks which do encourage using much of the same code on client and server. Some of the ReactJS stacks do, for example. The thing is, it turns out that what people want is proper separation of frontend and backend, not separation of client and server. Outside of single-page apps, there's a fair bit of "generate this page for me" stuff required as a baseline, but also a lot of places where if it's possible, rendering (and animating) on the client-side provides a better experience. GitHub's repository browsing is an example, as is Twitter's entire site, as is Google's Instant Search. So running the same view logic on the server and client is a good thing, as it results in not having to write it once for each environment. The controller glue for tying it to the model changes, but that can easily be switched out per environment without changing the view's code, and is often generic enough that it can be implemented at least in part by a library.