5 ms·

This just reads to me like "my personal preferences are good and things I don't like are hyped up and of dubious merit". If it were me, I'd prefer rails to dja

This just reads to me like "my personal preferences are good and things I don't like are hyped up and of dubious merit". If it were me, I'd prefer rails to django any day of the week, that's a personal preference, but if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views, which you need a js backend to do.

Scarbutt 6y ago
but if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views Is not worse, is fine. Mostly depends on the requirements, why go the extra complexity of SSR if you don't need it?
- putnambr 6y ago
  Most of the time SSR gives massive web accessibility benefits. Ignoring web accessibility because you don't want to implement SSR is likely a worse solution for a large portion of your userbase.
- root_axis 6y ago
  That's why I said "typically". One of the biggest complaints about SPAs is the perceived slowness due to the app loading and rendering assets in the browser, as well as the typical HN noscript complaints, as well as accessibility issues, SEO issues, and other problems related to back button behavior and url routing. SSR solves all of these troubles.
setr 6y ago
I've never been fully confident in knowing what SSR refers to -- but its just the creation of static html on the server, right? As opposed to shipping a bunch of async dom updates contained in a js script executing on load, client side But if I have it right, I have no idea why a JS backend would be required to do SSR; this is exactly the same domain of work php, rails, django have always done, without node.js needing to enter. For an SPA (which I believe is just a bunch of js fetching data from JSON apis and rendering client-side), you'd need JS to handle client-side rendering, but if you can replace that with WASM (when it has DOM support)... I don't see why you'd need JS anywhere FYI I'm defining everything because I'm pretty sure there's a mistake somewhere in my understanding of the problem
- steveklabnik 6y ago
  Nah it's used in two related, but kinda confusing ways, it's not just you: Traditionally, it means rendering your HTML on the server. Exactly what you're saying. It also refers to a specific technique that's used to implement rendering your HTML on the server by effectively running your client side app server side, then shipping its output. This requires some work to get right, and so it's presented as a feature of client-side libraries/frameworks.
  - setr 6y ago
    Ah The actual client code is being executed. Wait thats just weird -- if you're effectively removing the work from the client to the server anyways, such that its only executing on the server... I don't see what you've achieved beyond the original writing of standard language-agnostic SSR -- that you can design everything client-side, and conveniently migrate the heavier work serverside without interruption/rewrite?
    - steveklabnik 6y ago
      > such that its only executing on the server It's not, it can run on both. You render on the server for the initial page load, and then on the client for every page after. Or not! The point is, now that you've unlocked both, you can use either one, in the way that works best for your application, in whatever ratio makes sense.
    - nwienert 6y ago
      It gives you the best of both worlds - fast initial load, accessible, works without JS. But then also get all the client side goodness - highly interactive views, animations, and far less bytes transferred for subsequent page loads. Plus, writing a complex frontend is simply a far better experience in something like React than in Ruby, Python, PHP, etc. Finally, it lets you also render them to React Native using a lot of shared code. And you can share code between your backend APIs, etc. To be honest, I’ll take Typescript over anything, even if it wasn’t the default for the web. It strikes the perfect balance of flexibility, concision, safety, debugging ux, and has a huge ecosystem to boot. I think client side JS these days if anything is underrated and the WASM hype won’t change much - if you want a lightweight, accessible app then doing a SPA in JS (with SSR) is actually not even a compromise, it’s truly superior to any alternative. Now, with a big caveat: you need to invest to get it all set up properly. No one has really “railsed” it yet, as far as I can tell.
airstrike 6y ago
> If it were me, I'd prefer rails to django any day of the week, that's a personal preference This is totally not what the parent is getting into. It seems like your comment reads much more like "my personal preferences are good" than the parent
- root_axis 6y ago
  They complain about Javascript and Kubernetes then praise Django and Redis, all in the abstract without any consideration for the totally different problems these tools actually solve. I injected my own personal preferences in-kind but labeled them as preferences instead of slamming other tools as overhyped and without merit.
wtetzner 6y ago
I'm not sure exactly what you're referring to, but being able to run Rust both on the server and client should allow SSR, no?
there_the_and 6y ago
> if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views, which you need a js backend to do. I have not used React with Rails and maybe I'm misunderstanding your comment, but the react-rails readme includes a section about SSR via ExecJS and integrated with Rails: https://github.com/reactjs/react-rails#server-side-rendering https://github.com/reactjs/react-rails#server-side-rendering
- root_axis 6y ago
  ExecJS functions as a JS backend in this case, its just a ruby interface for node/rhino/v8 that's a little bit clunkier to utilize.
  - there_the_and 6y ago
    That is obvious (it's in the name). The way your comment is phrased reads to me like you are saying that one can't use Rails and has to switch to a full JS backend for SSR. If that's not what you are saying, then it's unclear what you are actually saying and why you juxtaposed Rails / Django against a JS backend.
    - root_axis 6y ago
      My point is that you literally cannot SSR your client js views without a js backend, so node has a clear engineering purpose in this respect. Yes, you can import a second backend into your main backend to avoid writing node, and that's fine, maybe your team is mostly made of rubyists or maybe your existing code base is ruby, there's nothing wrong with this approach, but it is more complication and layers of abstraction than just using a js backend if you must build an SPA.
      - there_the_and 6y ago
        > import a second backend into your main backend This is not typically how the term "backend" is used in this context. Most mature apps will use a variety of tools and services built in a variety of languages, but this is not referred to as "importing a second backend." In fact, your comment is apparently the first use of the phrase "import a second backend" on the entire internet: https://www.google.com/search?q=%22import+a+second+backend%22 https://www.google.com/search?q=%22import+a+second+backend%2...
deleted 6y ago
[deleted]
bitexploder 6y ago
To some extent, that is true regarding my personal preferences, but being in tech and writing code for over 20 years teaches you a few things. Developers should be more picky about tools they adopt without becoming too cynical or dismissive of new technology. Every so often you have to go through your technology shed and be sure you aren't being biased towards existing comfortable tools. It's nice to work out of your comfort zone and learn new things, but it's also nice to be very efficient at problem solving. When I feel a new tool or technology crosses a threshold from hype to having proved its value I tend to take it seriously and learn it. I try to avoid getting sucked into tech stacks that I don't think will make it. Some times I am wrong, but usually not. I could have made my description of technology more generic, but in general, things like Django/Rails/Postgres/MySQL/NodeJS/Redis are battle proven technology that won't let you down. IMO that is the hardest part about being a lead engineer / CTO -- knowing when to say Yes and No to given technology stacks :)
- root_axis 6y ago
  I agree with everything you've written here, particularly your process of tool evaluation and refinement. My only push back is with respect to the way you characterized the merit of "overhyped" tools (in your previous comment) that didn't line up with the productivity profile of your personal experience. I agree that Django/Rails/Postgres/MySQL/NodeJS/Redis are all reliable tools, but I am not a fan of the philosophy that labels other people's work as unnecessary or harmful simply for existing outside the pantheon of worthy tooling.
  - bitexploder 6y ago
    In isolation of any constraint new things are always worth playing with and trying. I know I am certainly more biased (hopefully in a mostly good way) now than I was when I started in tech. Your thought strikes me as Very similar to when someone shares some hobby project they are working on and someone else doesn’t get it and states: “wow, you must have a lot of time on your hands”. So I do try to take new projects seriously while at the same time balancing time constraints. It’s hard :)

Scarbutt 6y ago

but if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views Is not worse, is fine. Mostly depends on the requirements, why go the extra complexity of SSR if you don't need it?

putnambr 6y ago
Most of the time SSR gives massive web accessibility benefits. Ignoring web accessibility because you don't want to implement SSR is likely a worse solution for a large portion of your userbase.
root_axis 6y ago
That's why I said "typically". One of the biggest complaints about SPAs is the perceived slowness due to the app loading and rendering assets in the browser, as well as the typical HN noscript complaints, as well as accessibility issues, SEO issues, and other problems related to back button behavior and url routing. SSR solves all of these troubles.

setr 6y ago

I've never been fully confident in knowing what SSR refers to -- but its just the creation of static html on the server, right? As opposed to shipping a bunch of async dom updates contained in a js script executing on load, client side But if I have it right, I have no idea why a JS backend would be required to do SSR; this is exactly the same domain of work php, rails, django have always done, without node.js needing to enter. For an SPA (which I believe is just a bunch of js fetching data from JSON apis and rendering client-side), you'd need JS to handle client-side rendering, but if you can replace that with WASM (when it has DOM support)... I don't see why you'd need JS anywhere FYI I'm defining everything because I'm pretty sure there's a mistake somewhere in my understanding of the problem

steveklabnik 6y ago
Nah it's used in two related, but kinda confusing ways, it's not just you: Traditionally, it means rendering your HTML on the server. Exactly what you're saying. It also refers to a specific technique that's used to implement rendering your HTML on the server by effectively running your client side app server side, then shipping its output. This requires some work to get right, and so it's presented as a feature of client-side libraries/frameworks.
- setr 6y ago
  Ah The actual client code is being executed. Wait thats just weird -- if you're effectively removing the work from the client to the server anyways, such that its only executing on the server... I don't see what you've achieved beyond the original writing of standard language-agnostic SSR -- that you can design everything client-side, and conveniently migrate the heavier work serverside without interruption/rewrite?
  - steveklabnik 6y ago
    > such that its only executing on the server It's not, it can run on both. You render on the server for the initial page load, and then on the client for every page after. Or not! The point is, now that you've unlocked both, you can use either one, in the way that works best for your application, in whatever ratio makes sense.
  - nwienert 6y ago
    It gives you the best of both worlds - fast initial load, accessible, works without JS. But then also get all the client side goodness - highly interactive views, animations, and far less bytes transferred for subsequent page loads. Plus, writing a complex frontend is simply a far better experience in something like React than in Ruby, Python, PHP, etc. Finally, it lets you also render them to React Native using a lot of shared code. And you can share code between your backend APIs, etc. To be honest, I’ll take Typescript over anything, even if it wasn’t the default for the web. It strikes the perfect balance of flexibility, concision, safety, debugging ux, and has a huge ecosystem to boot. I think client side JS these days if anything is underrated and the WASM hype won’t change much - if you want a lightweight, accessible app then doing a SPA in JS (with SSR) is actually not even a compromise, it’s truly superior to any alternative. Now, with a big caveat: you need to invest to get it all set up properly. No one has really “railsed” it yet, as far as I can tell.

airstrike 6y ago

> If it were me, I'd prefer rails to django any day of the week, that's a personal preference This is totally not what the parent is getting into. It seems like your comment reads much more like "my personal preferences are good" than the parent

root_axis 6y ago
They complain about Javascript and Kubernetes then praise Django and Redis, all in the abstract without any consideration for the totally different problems these tools actually solve. I injected my own personal preferences in-kind but labeled them as preferences instead of slamming other tools as overhyped and without merit.

wtetzner 6y ago

I'm not sure exactly what you're referring to, but being able to run Rust both on the server and client should allow SSR, no?

there_the_and 6y ago

> if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views, which you need a js backend to do. I have not used React with Rails and maybe I'm misunderstanding your comment, but the react-rails readme includes a section about SSR via ExecJS and integrated with Rails: https://github.com/reactjs/react-rails#server-side-rendering https://github.com/reactjs/react-rails#server-side-rendering

root_axis 6y ago
ExecJS functions as a JS backend in this case, its just a ruby interface for node/rhino/v8 that's a little bit clunkier to utilize.
- there_the_and 6y ago
  That is obvious (it's in the name). The way your comment is phrased reads to me like you are saying that one can't use Rails and has to switch to a full JS backend for SSR. If that's not what you are saying, then it's unclear what you are actually saying and why you juxtaposed Rails / Django against a JS backend.
  - root_axis 6y ago
    My point is that you literally cannot SSR your client js views without a js backend, so node has a clear engineering purpose in this respect. Yes, you can import a second backend into your main backend to avoid writing node, and that's fine, maybe your team is mostly made of rubyists or maybe your existing code base is ruby, there's nothing wrong with this approach, but it is more complication and layers of abstraction than just using a js backend if you must build an SPA.
    - there_the_and 6y ago
      > import a second backend into your main backend This is not typically how the term "backend" is used in this context. Most mature apps will use a variety of tools and services built in a variety of languages, but this is not referred to as "importing a second backend." In fact, your comment is apparently the first use of the phrase "import a second backend" on the entire internet: https://www.google.com/search?q=%22import+a+second+backend%22 https://www.google.com/search?q=%22import+a+second+backend%2...

deleted 6y ago

[deleted]

bitexploder 6y ago

To some extent, that is true regarding my personal preferences, but being in tech and writing code for over 20 years teaches you a few things. Developers should be more picky about tools they adopt without becoming too cynical or dismissive of new technology. Every so often you have to go through your technology shed and be sure you aren't being biased towards existing comfortable tools. It's nice to work out of your comfort zone and learn new things, but it's also nice to be very efficient at problem solving. When I feel a new tool or technology crosses a threshold from hype to having proved its value I tend to take it seriously and learn it. I try to avoid getting sucked into tech stacks that I don't think will make it. Some times I am wrong, but usually not. I could have made my description of technology more generic, but in general, things like Django/Rails/Postgres/MySQL/NodeJS/Redis are battle proven technology that won't let you down. IMO that is the hardest part about being a lead engineer / CTO -- knowing when to say Yes and No to given technology stacks :)

root_axis 6y ago
I agree with everything you've written here, particularly your process of tool evaluation and refinement. My only push back is with respect to the way you characterized the merit of "overhyped" tools (in your previous comment) that didn't line up with the productivity profile of your personal experience. I agree that Django/Rails/Postgres/MySQL/NodeJS/Redis are all reliable tools, but I am not a fan of the philosophy that labels other people's work as unnecessary or harmful simply for existing outside the pantheon of worthy tooling.
- bitexploder 6y ago
  In isolation of any constraint new things are always worth playing with and trying. I know I am certainly more biased (hopefully in a mostly good way) now than I was when I started in tech. Your thought strikes me as Very similar to when someone shares some hobby project they are working on and someone else doesn’t get it and states: “wow, you must have a lot of time on your hands”. So I do try to take new projects seriously while at the same time balancing time constraints. It’s hard :)