Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Less context switching probably means two things:

* Mental context switch between server/client languages.

* Better code reuse, i.e. the same model class can be used on the server and client side.

Those things you're talking about are just protocols: storage protocol, transfer protocol, etc.



> * Mental context switch between server/client languages.

Not sure I follow. The client-side Javascript you write will probably interact with the DOM API. The server-side Javascript will probably interact with the filesystem of the server, it is BYOD (Bring Your Own DOM). Plus, no matter what, you will always have that switch between client/server because that switch is what defines client/server.

> * Better code reuse, i.e. the same model class can be used on the server and client side.

Does anyone actually do this? True, it is the same language, but it is not the same environment.


> ...it is the same language, but it is not the same environment.

It is for me. I'm building a framework and enterprise app that just targets V8 (Node server, Chrome client). It's very liberating, to say the least. I still use Firefox (Firebug) for experimental stuff though, as Chrome's dev tools aren't up to par yet.


I'm surprised to hear WebKit's DOM Inspector being compared unfavorably to Firebug. What's missing?


At least when I last used it, the error reporting was lacking. Errors'd hang the page and wouldn't give accurate messages/line numbers.


Sharing models makes doing some form validations MUCH easier. My template language also runs on both server and client making progressive enhancement pretty trivial (in terms of updating dom elements when models change)

As for context-switch on server/client... if you use something like underscore on both ends, lots of things end up looking the same.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: