4 ms·

This is a digression, but the book starts by saying that it's a benefit to the developer to have one language front and backend. I've been working on node/JS w

This is a digression, but the book starts by saying that it's a benefit to the developer to have one language front and backend. I've been working on node/JS web apps for several years now, so this is my lived reality, but I don't like that it's the same language front and backend. Just as a web page with HTML, JavaScript and CSS lets me mentally separate the different aspects of the front end and context switch more easily between them (I'm never confused about what I'm addressing), I've found having JS both front and back end (separated by a GraphQL API) to require being more conscious of my environment. There are subtle differences between Node and the browser VM; there are different concerns with resource usage and concurrent operations. When doing React I refused to follow Facebook's lead and relocate styles into the code. In my mind it just crowded the JavaScript and made for more code where multiple concerns where colocated. Am I the only one who felt this way?

cies 5y ago
> the book starts by saying that it's a benefit to the developer to have one language front and backend I also cringed at that premise. JS sucks a lot, having it on both sides would make things worse. Yes TS can help here, but only so much. You cannot make up for a languages design mistakes by bolting on a type system. Also: making a SPA-like browser app makes thing think about the state of the application twice! This comes at huge cost. Simple page-to-page applications with SSR are waaaay easier to build an maintain. When I do browser apps I prefer a strong-typed API spec from which I generate (1) client libs and (2) server stubs. This gives me some safety guarantees over the API barrier. Using a language like Elm with an "elm-graphql" generated client lib is a bliss. Compile gQL queries in a type safe manner: if it compiles it runs. I feel there is soo much more "tao" (simplicity, peace of mind, zen, less moving parts) in this approach than in the JS-article I just read.
- hombre_fatal 5y ago
  You can write this sort of guide for literally any tech, even the ones you think are better. I've been using Elm since it came out and I use it for everything, but you could write a "Tao of Elm" that's just as in-depth as this. Just watch rfeldman's talks about how to structure large Elm projects (https://www.youtube.com/watch?v=DoA4Txr4GUs https://www.youtube.com/watch?v=DoA4Txr4GUs) or watch the community chat about how to do it, it's an open question. For example, the Tao of Elm would give pointers on what you should send over ports, how granular you should even make ports, how to pick Msg types (LogIn User | LogOut vs. SetUser User), how to build a good Model, when to nest models, (a big one:) how to build parent/child communication, what should be implemented on the JS side instead of Elm side, how to represent fetch/wait/response loop when making http requests, etc. and then the trade-offs of all of those suggestions. Being able to compile a list of best practices doesn't mean something sucks. Though the comparison to Elm isn't all that great because it doesn't even compete with Node, and if you do use it on the server with Elm.worker, you could write a whole other guide of best practices around that. Anyone who has built a massive Elm client is shimmering with trail/error knowledge that they could share in this kind of format. Anyways, be wary of developing a knee-jerk "JS sucks" response.

cies 5y ago

> the book starts by saying that it's a benefit to the developer to have one language front and backend I also cringed at that premise. JS sucks a lot, having it on both sides would make things worse. Yes TS can help here, but only so much. You cannot make up for a languages design mistakes by bolting on a type system. Also: making a SPA-like browser app makes thing think about the state of the application twice! This comes at huge cost. Simple page-to-page applications with SSR are waaaay easier to build an maintain. When I do browser apps I prefer a strong-typed API spec from which I generate (1) client libs and (2) server stubs. This gives me some safety guarantees over the API barrier. Using a language like Elm with an "elm-graphql" generated client lib is a bliss. Compile gQL queries in a type safe manner: if it compiles it runs. I feel there is soo much more "tao" (simplicity, peace of mind, zen, less moving parts) in this approach than in the JS-article I just read.

hombre_fatal 5y ago
You can write this sort of guide for literally any tech, even the ones you think are better. I've been using Elm since it came out and I use it for everything, but you could write a "Tao of Elm" that's just as in-depth as this. Just watch rfeldman's talks about how to structure large Elm projects (https://www.youtube.com/watch?v=DoA4Txr4GUs https://www.youtube.com/watch?v=DoA4Txr4GUs) or watch the community chat about how to do it, it's an open question. For example, the Tao of Elm would give pointers on what you should send over ports, how granular you should even make ports, how to pick Msg types (LogIn User | LogOut vs. SetUser User), how to build a good Model, when to nest models, (a big one:) how to build parent/child communication, what should be implemented on the JS side instead of Elm side, how to represent fetch/wait/response loop when making http requests, etc. and then the trade-offs of all of those suggestions. Being able to compile a list of best practices doesn't mean something sucks. Though the comparison to Elm isn't all that great because it doesn't even compete with Node, and if you do use it on the server with Elm.worker, you could write a whole other guide of best practices around that. Anyone who has built a massive Elm client is shimmering with trail/error knowledge that they could share in this kind of format. Anyways, be wary of developing a knee-jerk "JS sucks" response.