3 ms·
(This response is to JS on the client-side) Why does the thought of writing view logic in Javascript make me cringe? I've written very complex client side jav
by alttab 16y ago
(This response is to JS on the client-side)
Why does the thought of writing view logic in Javascript make me cringe?
I've written very complex client side javascript in the past, and I've become somewhat of a minimalist.
I speak nothing of node.js because I haven't used it, but if this was used on the client side I would barf. If a user is on IE vs Safari vs Firefox, it will perform completely different - which is extremely important when the javascript that is executing renders something to the screen. Users have very little wiggle-room for what they consider "snappy".
IMO, javascript should only be given HTML blocks from the server when rendering larger, more complex partials. This is because if you do it client side (maybe to save the server from rendering HTML and the round trip), you have skattered your view from server-page rendering into javascript CODE. You can test page-renders on the back end, but you need to run a full document emulator (which one, mind you?) to test anything rendered in javascript. I can't count the number of times something in the UI has changed on the backend and we don't find out the javascript fails until later.
I understand the "JS for everything" movement, but I'd be more inclined to bring Ruby into the browser. Javascript is syntax-heavy (especially when creating strings), hard to test, develops slowly, and doesn't provide stack-traces or logs in the event you need to provide end-user support when something goes wrong.
Javascript in my experience is best when used as a conduit - not a swiss army knife.