4 ms·

The tools are sophisticated but also much harder to use. Things like modern front end JavaScript and Kubernetes are very complex beasts to tame. Their value is

The tools are sophisticated but also much harder to use. Things like modern front end JavaScript and Kubernetes are very complex beasts to tame. Their value is dubious for many use cases people choose them for, but they are undeniably powerful tools that advance the state of art by a lot. Same with NoSQL. It became hyped and overused but some really powerful and easier to use technology eventually emerged from it and gave us things like Redis, Redis now is a part of most modern web app stacks. I still just use Django and a lot of server side HTML templates. Developers often have a hard time knowing when to use a given technology and often end up bringing tech into their stack they don’t need. This plays out in 5-8 year cycles. Meanwhile RDBMS and simple things like Django with minimal front end JavaScript can still solve the vast majority of problems people have in the web app space. It’s the classic hype/adoption/cynicism cycle we have had forever.

root_axis 6y ago
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.
- 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 :)

root_axis 6y ago

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.
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 :)