4 ms·

I code a lot in JS these days and I find this divide suggestion interesting. Though I'm proficient in JS, I don't trust myself enough to write server stuff in J

I code a lot in JS these days and I find this divide suggestion interesting. Though I'm proficient in JS, I don't trust myself enough to write server stuff in JS - for ex: while an accidental global access likely has limited consequences on the browser side, it can result in data cross talk between users on the server side. So I do prefer the help offered by some static typing. Even go feels better, Haskell would rock, typed racket also looks awesome from this perspective. To my main point, I'm unclear how such a split would actually work in practice. For example, if I have a file upload to do from the client, should that get streamed to the "ui front end at the back end" (whew!) or directly to the "real back end"? Are there any fundamental architectural problems with client side code pulling together an application by accessing a number of independent REST services without going through such a "front end at the back end"? Thoughts/suggestions?

ilaksh 13y ago
I don't understand what you mean by "ui front end at the back end". I think maybe I can guess but really not sure at all. I don't see how static typing is really necessary to prevent you from storing user-specific data in a global and sending someone another user's data. Seems like that would be fairly straightforward to detect and avoid and I don't think you would usually be tempted to use a global for something like that. You could use a session variable or database. If you have never worked on the back end, then you are right to be afraid of doing something wrong. However, you are incorrect if you think that means you are likely to make a serious error that you can't correct and therefore shouldn't try. Back end programming is in fact less complex than front-end programming today. So you should jump in. You will learn the most important things you need within a few months. When you upload a file this generally happens as an HTTP POST. Usually this is sent to your own back-end server code. And without special headers on the target domain your browser won't even allow you to POST to another third-party server. This I think is the issue you are talking about when you mention accessing independent REST services -- that needs to use JSONP or have CORS enabled on the third party server. Of course you may not need to learn anything about back-end programming because you can in fact build just about any kind of application these days without using your own server at all, just by integrating a number of third-party APIs and running everything from the browser.
- aufreak3 13y ago
  Thanks for responding. By "ui front end at the back end", I was referring to the OP's suggestion to use nodejs as the entry point which the talks to the "real" back end. I'm interested in real time collaboration where message connections between connected users are easiest held in a shared data structure to reduce latency. I've on occasion mangled this data structure unintentionally without any feedback from JS before deployment. If I'd had some static checking, these problems would've been easily avoided. Hence my fear. edit: to be clear, my "fear" only applies to languages like JS and untyped racket at the backend. Not of backend programming per se. Rgd my example, so ... given that I would needs CORS support, the browser->nodejs->backend division of labour that the OP is suggesting doesn't seem workable for such a file upload case.

ilaksh 13y ago

I don't understand what you mean by "ui front end at the back end". I think maybe I can guess but really not sure at all. I don't see how static typing is really necessary to prevent you from storing user-specific data in a global and sending someone another user's data. Seems like that would be fairly straightforward to detect and avoid and I don't think you would usually be tempted to use a global for something like that. You could use a session variable or database. If you have never worked on the back end, then you are right to be afraid of doing something wrong. However, you are incorrect if you think that means you are likely to make a serious error that you can't correct and therefore shouldn't try. Back end programming is in fact less complex than front-end programming today. So you should jump in. You will learn the most important things you need within a few months. When you upload a file this generally happens as an HTTP POST. Usually this is sent to your own back-end server code. And without special headers on the target domain your browser won't even allow you to POST to another third-party server. This I think is the issue you are talking about when you mention accessing independent REST services -- that needs to use JSONP or have CORS enabled on the third party server. Of course you may not need to learn anything about back-end programming because you can in fact build just about any kind of application these days without using your own server at all, just by integrating a number of third-party APIs and running everything from the browser.

aufreak3 13y ago
Thanks for responding. By "ui front end at the back end", I was referring to the OP's suggestion to use nodejs as the entry point which the talks to the "real" back end. I'm interested in real time collaboration where message connections between connected users are easiest held in a shared data structure to reduce latency. I've on occasion mangled this data structure unintentionally without any feedback from JS before deployment. If I'd had some static checking, these problems would've been easily avoided. Hence my fear. edit: to be clear, my "fear" only applies to languages like JS and untyped racket at the backend. Not of backend programming per se. Rgd my example, so ... given that I would needs CORS support, the browser->nodejs->backend division of labour that the OP is suggesting doesn't seem workable for such a file upload case.