4 ms·

RPC - this isn't anything new. When I started doing web development in the late 90s for about ~5 years I was the designer, front-end, and backend developer all

RPC - this isn't anything new. When I started doing web development in the late 90s for about ~5 years I was the designer, front-end, and backend developer all in one. Then over time things changed to allow for specializations and we now have many different functions, and that's a good thing. RPC has a place, and it's not for web apps, at least most of the time. I've noticed over the years that JavaScript developers tend to try and put their JavaScript everywhere and I often wonder if it's because they don't want to learn other technologies. Don't get me wrong, I like a little bit of JS too - I even added JavaScript support to an old 2D Game engine using SpiderMonkey (before V8 was a thing) back in the day so that I could make desktop games with JavaScript. I just don't want to do _everything_ with JavaScript. Especially with so many interesting languages and technologies to play with these days. Are JavaScript developers today the PHP guys of the past?

bradlys 7y ago
I'd imagine it's probably a business thing as well. The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Where I work, having one language has made things simpler when doing tasks. Don't need to look things up as much because you keep forgetting which one uses push vs append, etc.
- js8 7y ago
  > The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Oh, you're a poet, right? I need you to write some legal documents. You are already expert in English, so it should be easy.
  - z3t4 7y ago
    Easier then writing it in another language. And you would get even better when you also know legal talk. That happened to me when I switched to full stack JS, I became so much better at JS, made it possible to write much simpler code. Doing very complex things with basic language constructs.
z3t4 7y ago
Wouldn't you prefer to talk in your mother language instead of using a new language for every country you visit?
- adjkant 7y ago
  At first, but not if it made it harder to communicate in each country I visited if I was visiting those countries regularly. I think the parent is likely onto something in that the spread of JS into backend services is not beneficial to those who spend most of their time on the backend, but it beneficial to those who don't. That's IMO creating an inherent tension. Personally I have never understood backend JS as you get untyped, weird silent errors, under or completely un-utilized async features that end up causing more problems than they solve, and then all the quirks of JS to boot. I regularly hear the argument of the benefits of keeping the language the same on both ends, but besides slightly easier JSON between them (something handled by clean packages in almost every language these days with minimal effort/LOC/boilerplate) the languages don't end up actually sharing a ton given how you hook into a web framework like Express, database API's, etc. You don't get code reusability and I don't think the JS tradeoffs are worth the slight savings on context switching. If you have a serious project of any scale/long term use and have front end programmers that want to use JS on the backend, either bite the bullet and have them learn now or hire some backend devs in a language better suited to your project.
  - z3t4 7y ago
    As someone coming from web dev to back-end JS I take with me the love for instant feedback, which allows for extensive manual testing during development. And I also use automatic regression tests before pushing to prod. Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production. I usually take a front-end first aproach, but there are also lots of people taking a backend first aproache where they rely more on static analysis, compilation, unit tests and packaging - rather then manually testing every LOC.
    - theamk 7y ago
t0astbread 7y ago
Play with? Sure. But for actually doing "the real thing" reusing tech you already have expertise in seems more efficient than trying to gain an equal amount of expertise in another technology. Add to that, if you're in a hurry you don't even have the time to learn anything new.
mvila 7y ago
For now, Liaison is JS-focused. So both the frontend and the backend have to be implemented in JS. But the communication protocol (https://deepr.io https://deepr.io) in between is language agnostic. So it is possible to imagine Liaison being ported to different languages in the future.
- brillout 7y ago
  I've been thinking about language agnostic RPC as well. That would be so neat! gRPC can already do that but gRPC's design is unnecessary bloated. The nice thing about RPC is its potential of zero-config setup. gRPC totally fails on that and it's painful to setup gRPC. The RoR/python server could be used to automatically serve the RPC API. For a zero-config setup.

bradlys 7y ago

I'd imagine it's probably a business thing as well. The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Where I work, having one language has made things simpler when doing tasks. Don't need to look things up as much because you keep forgetting which one uses push vs append, etc.

js8 7y ago
> The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Oh, you're a poet, right? I need you to write some legal documents. You are already expert in English, so it should be easy.
- z3t4 7y ago
  Easier then writing it in another language. And you would get even better when you also know legal talk. That happened to me when I switched to full stack JS, I became so much better at JS, made it possible to write much simpler code. Doing very complex things with basic language constructs.

z3t4 7y ago

Wouldn't you prefer to talk in your mother language instead of using a new language for every country you visit?

adjkant 7y ago
At first, but not if it made it harder to communicate in each country I visited if I was visiting those countries regularly. I think the parent is likely onto something in that the spread of JS into backend services is not beneficial to those who spend most of their time on the backend, but it beneficial to those who don't. That's IMO creating an inherent tension. Personally I have never understood backend JS as you get untyped, weird silent errors, under or completely un-utilized async features that end up causing more problems than they solve, and then all the quirks of JS to boot. I regularly hear the argument of the benefits of keeping the language the same on both ends, but besides slightly easier JSON between them (something handled by clean packages in almost every language these days with minimal effort/LOC/boilerplate) the languages don't end up actually sharing a ton given how you hook into a web framework like Express, database API's, etc. You don't get code reusability and I don't think the JS tradeoffs are worth the slight savings on context switching. If you have a serious project of any scale/long term use and have front end programmers that want to use JS on the backend, either bite the bullet and have them learn now or hire some backend devs in a language better suited to your project.
- z3t4 7y ago
  As someone coming from web dev to back-end JS I take with me the love for instant feedback, which allows for extensive manual testing during development. And I also use automatic regression tests before pushing to prod. Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production. I usually take a front-end first aproach, but there are also lots of people taking a backend first aproache where they rely more on static analysis, compilation, unit tests and packaging - rather then manually testing every LOC.
  - theamk 7y ago

t0astbread 7y ago

Play with? Sure. But for actually doing "the real thing" reusing tech you already have expertise in seems more efficient than trying to gain an equal amount of expertise in another technology. Add to that, if you're in a hurry you don't even have the time to learn anything new.

mvila 7y ago

For now, Liaison is JS-focused. So both the frontend and the backend have to be implemented in JS. But the communication protocol (https://deepr.io https://deepr.io) in between is language agnostic. So it is possible to imagine Liaison being ported to different languages in the future.

brillout 7y ago
I've been thinking about language agnostic RPC as well. That would be so neat! gRPC can already do that but gRPC's design is unnecessary bloated. The nice thing about RPC is its potential of zero-config setup. gRPC totally fails on that and it's painful to setup gRPC. The RoR/python server could be used to automatically serve the RPC API. For a zero-config setup.