5 ms·

I was worried that an application I was building in Django, with a frontend built with Bootstrap and some LIGHT jquery was making me look like an old curmudgeon

I was worried that an application I was building in Django, with a frontend built with Bootstrap and some LIGHT jquery was making me look like an old curmudgeon but the part about testability of the frontend really resonated with me. It was MUCH easier to structure everything as pytest unit tests and completely rely on Django for all the business logic rather than trying to put state in the frontend and deal with synchronizing states between FIVE distinct systems (remote devices, the Django application, the database, an event stream, AND the front end). I recognize that I'm not hip or with it, because I really fell out of front end development at the peak of jQuery where it was mostly about fixing browser incompatibilities, but it's nice to see that maybe it went too far in the other direction and we're overdue for a bit of a swing back towards server side.

pinoy420 2y ago
Serverside rendering is apparently a new technology now. And this brand new thing called islands which someone reinvented recently.
- emptiestplace 2y ago
  It's back, but the nice thing is it's 10x more complicated now!
  - khana 2y ago
    [dead]
  - mattmanser 2y ago
    And in slow javashit!
    - otabdeveloper4 2y ago
      So, an overall win for software developers and cloud providers?
- belter 2y ago
  Oh no. So Java JSF was right after all? :-)
  - pjmlp 2y ago
    Yep, time to dust off PrimeFaces.
    - egeozcan 2y ago
      PrimeFaces is very well-maintained and regularly updated. I'd even go further and say that it's one of the few things that makes working with JSF bearable for me. I'm still a thousand times more productive with React though, and PrimeReact also helps there.
    - ramesh31 2y ago
      >Yep, time to dust off PrimeFaces. You joke, but PrimeReact and PrimeVue are some of the best libs out there today, due largely to that heritage. Great company.
      - pjmlp 2y ago
        Sure, it has always been the best JSF framework.
  - imtringued 2y ago
    No, the only project I've worked on that was a massive failure was built with Java JSF.
    - jbverschoor 2y ago
      Salesforce's visualforce pages are JSF though
- spockz 2y ago
  What are islands? The new servlets?
  - shreddit 2y ago
    Smallish parts of JS (React, Vue, ...) sprinkled into your website for interactivity. I use it with AstroJS: https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/
    - ehnto 2y ago
      I straddle the fence here, I think we jump down people's throats a bit too quickly when it comes to putting names on their new library. But I do also wish we'd stop reinventing things and patting ourselves on the back in other cases. Eg we are definitely working backwards from SPAs now. "JavaScript islands" were how we got to SPA frameworks in the first place. I don't have all the history and references, but anyone working in web in the late 2000s and 2010s can attest to how progressively adding in javascript on server side rendered HTML was already happening, even componentizing the server side code with CSS and JS packaged up was very common. "The term “component island” was first coined by Etsy’s frontend architect Katie Sylor-Miller in 2019. This idea was then expanded on and documented in this post by Preact creator Jason Miller on August 11, 2020." My only gripe, is that this leads the ready on an alternate history of how we got here.
      - themgt 2y ago
        The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions […] that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML. cryogenic lab tech: Welcome to the world of tomorrow!
        jbverschoor 2y ago
        portlets
deleted 2y ago
[deleted]
DanielHB 2y ago
Just because you have an SPA doesn't mean you need any state in the frontend. Main problem with react devs is just overcomplicating and over-abstracting stuff. The best way to explain it to a backend person is like the same interpersonal problems with overengineered microservices architectures.
- tiew9Vii 2y ago
  redux-query seems a popular library for dealing with API calls in react. I’ve landed on a project using it. By default it seems to maintain its own cache in the frontend of all api requests unless you use a non ergonomic feature “useLazy*” where you can give it hint if to use the local cache or not. It’s completely terrible in a web app! Web is distributed and multi user by default. End result with the app I’m working on if user a adds an item in one browser session, user b goes to a list view they don’t see the update, they see the redux-query cache. It’s an over complicated mess for an already solved problem. Have the server send proper cache-control headers and let the browser deal with the caching instead of trying to build fat clients on a web app that should be thin clients. You are right you don’t need to maintain state on the client but all these fashionable JavaScript frameworks promote doing just that.
  - the_other 2y ago
    That sounds like an application architecture problem, not problem with react or redux-query.
    - tiew9Vii 2y ago
      It is an application problem, agreed. It’s an application problem caused as a result of choosing the library, a common recommended library, and how the library and its documentation promotes its usage. The tools used were as the tools recommend. Admittedly, joining the project the wrong tools for the job were selected but these are all the react standard supporting libs. The application should have been architected not to use redux-query, instead use the browser fetchApi and server side cache control headers as we own the entire stack. Today that’s controversial as ”every body uses” and “this is what the docs recommends”
aryonoco 2y ago
Using a SPA doesn't mean ignoring software engineering principles. At my work we develop web applications for a mission critical sector (emergency services). We use .net for the backend (we have also used golang in some projects) and Typescript and Angular for the frontend. We follow MVVP patterns, SOLID principles, etc. There are multiple layers, each layer has a well defined single responsibility. Our applications have been quite successful with happy users and great maintainability if I may say so. There is nothing special about our setup. We could have used Vue.js or react for the frontend. We could have used any platform to build REST endpoints (though personally I like strongly typed languages for implementing business logic and think .net is underrated). Software engineering might not be as old as say civil engineering, but we've been doing it for decades now and have a rich library of patterns and architecture types to draw from. I've been building software for over 25 years; the technology stack might have changed in that time but the principles are still very much the same or are extensions of the previous ones. Using a SPA doesn't change the fact that if you want to build good applications, you first have to design them.

pinoy420 2y ago

Serverside rendering is apparently a new technology now. And this brand new thing called islands which someone reinvented recently.

emptiestplace 2y ago
It's back, but the nice thing is it's 10x more complicated now!
- khana 2y ago
  [dead]
- mattmanser 2y ago
  And in slow javashit!
  - otabdeveloper4 2y ago
    So, an overall win for software developers and cloud providers?
belter 2y ago
Oh no. So Java JSF was right after all? :-)
- pjmlp 2y ago
  Yep, time to dust off PrimeFaces.
  - egeozcan 2y ago
    PrimeFaces is very well-maintained and regularly updated. I'd even go further and say that it's one of the few things that makes working with JSF bearable for me. I'm still a thousand times more productive with React though, and PrimeReact also helps there.
  - ramesh31 2y ago
    >Yep, time to dust off PrimeFaces. You joke, but PrimeReact and PrimeVue are some of the best libs out there today, due largely to that heritage. Great company.
    - pjmlp 2y ago
      Sure, it has always been the best JSF framework.
- imtringued 2y ago
  No, the only project I've worked on that was a massive failure was built with Java JSF.
  - jbverschoor 2y ago
    Salesforce's visualforce pages are JSF though
spockz 2y ago
What are islands? The new servlets?
- shreddit 2y ago
  Smallish parts of JS (React, Vue, ...) sprinkled into your website for interactivity. I use it with AstroJS: https://docs.astro.build/en/concepts/islands/ https://docs.astro.build/en/concepts/islands/
  - ehnto 2y ago
    I straddle the fence here, I think we jump down people's throats a bit too quickly when it comes to putting names on their new library. But I do also wish we'd stop reinventing things and patting ourselves on the back in other cases. Eg we are definitely working backwards from SPAs now. "JavaScript islands" were how we got to SPA frameworks in the first place. I don't have all the history and references, but anyone working in web in the late 2000s and 2010s can attest to how progressively adding in javascript on server side rendered HTML was already happening, even componentizing the server side code with CSS and JS packaged up was very common. "The term “component island” was first coined by Etsy’s frontend architect Katie Sylor-Miller in 2019. This idea was then expanded on and documented in this post by Preact creator Jason Miller on August 11, 2020." My only gripe, is that this leads the ready on an alternate history of how we got here.
    - themgt 2y ago
      The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions […] that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML. cryogenic lab tech: Welcome to the world of tomorrow!
      - jbverschoor 2y ago
        portlets

deleted 2y ago

[deleted]

DanielHB 2y ago

Just because you have an SPA doesn't mean you need any state in the frontend. Main problem with react devs is just overcomplicating and over-abstracting stuff. The best way to explain it to a backend person is like the same interpersonal problems with overengineered microservices architectures.

tiew9Vii 2y ago
redux-query seems a popular library for dealing with API calls in react. I’ve landed on a project using it. By default it seems to maintain its own cache in the frontend of all api requests unless you use a non ergonomic feature “useLazy*” where you can give it hint if to use the local cache or not. It’s completely terrible in a web app! Web is distributed and multi user by default. End result with the app I’m working on if user a adds an item in one browser session, user b goes to a list view they don’t see the update, they see the redux-query cache. It’s an over complicated mess for an already solved problem. Have the server send proper cache-control headers and let the browser deal with the caching instead of trying to build fat clients on a web app that should be thin clients. You are right you don’t need to maintain state on the client but all these fashionable JavaScript frameworks promote doing just that.
- the_other 2y ago
  That sounds like an application architecture problem, not problem with react or redux-query.
  - tiew9Vii 2y ago
    It is an application problem, agreed. It’s an application problem caused as a result of choosing the library, a common recommended library, and how the library and its documentation promotes its usage. The tools used were as the tools recommend. Admittedly, joining the project the wrong tools for the job were selected but these are all the react standard supporting libs. The application should have been architected not to use redux-query, instead use the browser fetchApi and server side cache control headers as we own the entire stack. Today that’s controversial as ”every body uses” and “this is what the docs recommends”

aryonoco 2y ago

Using a SPA doesn't mean ignoring software engineering principles. At my work we develop web applications for a mission critical sector (emergency services). We use .net for the backend (we have also used golang in some projects) and Typescript and Angular for the frontend. We follow MVVP patterns, SOLID principles, etc. There are multiple layers, each layer has a well defined single responsibility. Our applications have been quite successful with happy users and great maintainability if I may say so. There is nothing special about our setup. We could have used Vue.js or react for the frontend. We could have used any platform to build REST endpoints (though personally I like strongly typed languages for implementing business logic and think .net is underrated). Software engineering might not be as old as say civil engineering, but we've been doing it for decades now and have a rich library of patterns and architecture types to draw from. I've been building software for over 25 years; the technology stack might have changed in that time but the principles are still very much the same or are extensions of the previous ones. Using a SPA doesn't change the fact that if you want to build good applications, you first have to design them.