But that doesn't give any meaningful advantage. Want to do your database queries to the client? Your business logic? No. Want to put frontend engineers to write your backend?
Lots of bad ideas. I mean, it is an ok feature, but by no means a killer-feature really. Ocsigen does the same thing: you can write your code in OCaml and the client-side part will by translated to JS automatically. Neat? Yes. Killer-feature? Probably not.
And JavaScript is really not that great to start with, so daveloping in something else server-side is not the worst idea.
The powerful use of JavaScript for me is that I can render the exact same templates on the server and the client. That's a lifesaver when you want a fast, client-based app that is also search engine indexable.
And JavaScript is really not that great to start with
It's fine. IMO, all languages have warts you have to work around, once you know them it becomes a non-issue. I can't think of the last time one of those "JavaScript WTF" moments actually tripped me up in real code.
I guess what I mean there is less let's have front end devs write our backend but that the ecosystem is so huge and that so many people know JS that it's a huge advantage. Nearly every single web developer that's been working over the last 20 years knows some level of javascript. No other language enjoys that advantage.
The Language, (in this case JavaScript) is probably the smallest part of domain knowledge needed to be a good front-end or back-end engineer. Front-end engineer, know JavaScript? OK, optimize these queries, do we need to cache, make temp tables, map/redux against the DW, etc? Hey backend developer, know JavaScript? Why won't this render the same in Chrome 33.1 as it does IE 10...etc...
JavaScript is a convenience language across the stack for when the team is small, or even a single person.
The problem with web dev (I've thought about this a lot) is really that the browser is kindof the hinge. So no matter what you do for unifying languages, even porting modules so they're same on node front to back-end... you still can't really ever get to a point where you're unit testing pretty reliably through the full-stack.
So might as well test parts in isolation & who cares if there is one language throughout the whole stack as long as your devs are good at the languages required.
One day I think the impedance between server & client will disappear, but only when the browser's role as a rendering engine diminishes or finds better integration/intimacy with the codebase.
(and incidentally, i stopped caring so much about this struggle once i learned how to develop pretty reliable SOA. Haven't totally given up trying to conceptualize the perfect stack tho)
Lots of bad ideas. I mean, it is an ok feature, but by no means a killer-feature really. Ocsigen does the same thing: you can write your code in OCaml and the client-side part will by translated to JS automatically. Neat? Yes. Killer-feature? Probably not.
And JavaScript is really not that great to start with, so daveloping in something else server-side is not the worst idea.