5 ms·

> Last years, using MVC framework was not an option as soon as you wanted a dynamic front-end. Having to reload a full page for every user action leads to a bad

by mod 4y ago

> Last years, using MVC framework was not an option as soon as you wanted a dynamic front-end. Having to reload a full page for every user action leads to a bad user experience and is indeed, not acceptable in 2022. When it's needed, fine. But there are so many SPAs that just don't need to be. Rendering HTML server-side is just nice. It's simple and easy to work with. Weird states are unusual. The user gets a really normalized, predictable experience. And done well/quickly, there's little actual difference. Maybe I'm just showing my age. This falls really close to my "I miss the old web" type sentiments. The last thing I built, and the next thing I will build, are purposely doing full page renders for any actions (no jQuery or React/SPA stuff). I don't think I'm going to have any javascript at all. It's really fun and lean. I don't know, it's just got me going lately--reminds me of when I was starting out. My last project is 300 lines of python, 270 lines of php, html/css of course, postgresql, and cron. Some scrapers run, ingest data, and the php sorts and displays it.

moonchrome 4y ago
In my experience server side rendering becomes really messy once you hit complex state management. Shuffling shit between pages, persistent vs transient state, handling reload/resubmit logic, validation. It works for simple stuff but even then I think once SPA tech matures more (ironically even after all this time I think transpilers/bundlers/package managers in JS still have a long way to go to get out of the way and frameworks are still far from optimal) anything that's not a web page should handle UI logic on the front-end.
- zippercreatemy 4y ago
  WHAT??? Okay I am going to bite, state is managed by the browser and then SPAs came along and tried to hack the state management ever since. I remember creating SPAs in 2004 when it was called AJAX and there was the debate of HTML or JSON over the wire. The biggest issue was back and forward buttons, even today that issue is not solved very well by SPAs. The issue I have is we had a great idea to refresh parts of a page with AJAX and then we went overboard and tried to move the entire application to complex frameworks which add more problems then they solve. We became so scared of screen rendering we avoided at all costs. This is bad UX as users actually get good confirmation that something has happened when there is a screen refresh.
- marginalia_nu 4y ago
  All code, across all paradigms, frontend, backend, low level, high level, whatever; all code becomes really messy when you have complex state management. The solution in each of these cases is the same, though. To simplify the state. In general, I think a lot of the pain in web development comes from attempting to have shared mutable state between backend and frontend. Shared mutable states are almost always messy. You can get around that by pushing it all to the frontend, or pushing it all to the backend. It's when it's straddling both you're in for a headache.
  - moonchrome 4y ago
    I agree - but you can't simplify when your tools complicate - in the sense that they intertwine different concerns. As soon as you're not dealing with trivial apps "pushing it all to backend" isn't really an option if you want good user experience - and then you'll have to have logic on frontend as well. And that's where the pain comes.
hsbauauvhabzb 4y ago
You only need what’s appropriate. I doubt missile launch systems are using react or whatever fancy frontend engineers want to use. SPAs are responsive which is nice, but some projects could better spend their time ensuring the project actually functions.
- hawkeyedan 4y ago
  Sadly, that might not be a great bet. The world of government software procurement is very, very ugly.
mxmxnxor 4y ago
>Rendering HTML server-side is just nice No, rendering html server-side is not nice and never was. Why on earth you will send markup template for every list item over and over again instead of sending just data and only one code-template (to render data on a client) ? Suppose you need to show to user a list of books on your web-page. Server side rendering means you need to send to user a markup consists of html elements for every book <div> <div class="book"> <div class="book-title">Book 1</div> <div class="book-author">Author 1</div> <div class="book-description">..description..</div> </div> <div class="book"> <div class="book-title">Book 2</div> <div class="book-author">Author 1</div> <div class="book-description">..description..</div> </div> <div class="book"> <div class="book-title">Book 2</div> <div class="book-author">Author 2</div> <div class="book-description">..description..</div> </div> </div> ... Don't you see something wrong with this? Why you need to duplicate over and over again html template for every list item resulting of significant increase of size of page to download if you can send only one template-component like this <div> <div class="book"> <div class="book-title">{book.title}</div> <div class="book-author">{book.author}</div> <div class="book-description">{book.description}</div> </div> </div> and a data in a more compact way [{title: "Book 1", author: "Author 1", description: "..."}, {title: "Book 1", author: "Author 1", description: "..."}, ...] or more compact like this [["Book 1", "Author 1", "..."],["Book 1", "Author 1", "..."], ...] or even in more compact binary-encoded format resulting in more than magnitude size compaction comparing to over-duplication html-approach. More size means more traffic for users to download over network and users which use data-roaming will "thank" you for your hundreds of kilobytes instead of dozens This is why server-side rendering approach was flawed from the beginning (not because of page reloading but because of data duplication and traffic consumption)
- inb4_cancelled 4y ago
  Two words: HTTP compression
  - louissan 4y ago
    a third word: DIVitis. but yeah, gzip or the more recent ones such as brotli have been taking care of those things for 25 years.... so HTML server-side has always been nice. Especially semantic markup cough cough
mmcnl 4y ago
Rendering server-side HTML is fine, as long as your application is stateless. Then it's really easy. However, when your application becomes more interactive and thus state-driven, is it really easier to it server-side? Remember, the primary function of modern frameworks is to have a declarative way of creating your by writing it as a function of state. Things get messy really quickly once you start to build something more complex. Also, is it really easier to everything on the server? I don't think it is so by definition. You could argue that a stateless REST API with client-side state management is less complex than doing everything server-side. It's a much more scalable solution and creating interactive user interfaces is very easy. Ofcourse it could be that interactive user interfaces is not something you are aiming for. That's fine. But do understand that most applications are actually usually very interactive.
- mattmanser 4y ago
  Yes, it is. That's what databases and POST data is for and it's all incredibly quick. Almost all applications that are written in the world today are glorified forms. That's reality because 95% of apps are written for the business world. Most don't really do much apart from take some form data, apply business logic to it and show the results/send some messages. Even most consumer apps like Facebook/Twitter/TikTok/Pintrest/etc. are basically glorified forms. You can do save/load state all in nanoseconds, any competent programmer can easily aim for 50ms page loads, well under human detection. This is incredibly basic stuff and how it was done for decades before SPAs.
  - feoren 4y ago
    You have rose-colored classes for the past. Multiple-megabyte state cookies were very common in business applications written in .NET WebForms, because even simple CRUD business applications have a lot of state to carry around that nowadays is simply managed in-memory by JavaScript. 50ms load times were out of the question; you were lucky if you could do it in 500ms. No "competent programmer" could do anything about this because WebForms didn't let them. As soon as you needed to filter one dropdown based on another dropdown, you needed to write custom JavaScript anyway. Writing a stateful front-end that just asks for what it needs from a well-built API when it needs it is enormously simpler than trying to store all state in some server session and having to work around your own framework whenever you need a dynamic dropdown list. We all seem to have collectively forgotten how awful web frameworks used to be, and how little interactivity the user actually expected. Things are way better now.
sanderjd 4y ago
Of the people I know who hold this view I know many software developers and zero other people. Even other very technical people, like data scientists, prefer an interactive interface to a series of pages.
- gamblor956 4y ago
  Of the people I know, ranging from programmers to HR people, most of them prefer the series of pages over the interactive interface for business processes. The series of pages makes it obvious that something has happened in response to input. OTOH, for stuff like Facebook they absolutely prefer the interactive interface.
  - sanderjd 4y ago
    The business people I know would mostly rather just do their business processes in Excel rather than a web browser :)
- zhte415 4y ago
  Almost everyone I know likes to have an expected response when pressing a button. In fact, I don't know anyone that doesn't.
  - sanderjd 4y ago
    This seems like an orthogonal question? I agree that whatever technology one chooses, buttons should be responsive when pressed. A page load is not the only kind of button press response that is possible.
bsder 4y ago
> Rendering HTML server-side is just nice. It's simple and easy to work with. Weird states are unusual. The user gets a really normalized, predictable experience. And done well/quickly, there's little actual difference. It has also been forgotten that people used to complain about 100ms of latency. Since then, modern users (especially mobile) have been trained to accept horrible latencies that would have gotten you excoriated back in 2000. 100ms of latency is MUCH more difficult to deal with server side than 2-3 seconds of latency. 2-3 seconds is an eternity with modern clouds and modern network connections.

by mod 4y ago

moonchrome 4y ago

In my experience server side rendering becomes really messy once you hit complex state management. Shuffling shit between pages, persistent vs transient state, handling reload/resubmit logic, validation. It works for simple stuff but even then I think once SPA tech matures more (ironically even after all this time I think transpilers/bundlers/package managers in JS still have a long way to go to get out of the way and frameworks are still far from optimal) anything that's not a web page should handle UI logic on the front-end.

zippercreatemy 4y ago
WHAT??? Okay I am going to bite, state is managed by the browser and then SPAs came along and tried to hack the state management ever since. I remember creating SPAs in 2004 when it was called AJAX and there was the debate of HTML or JSON over the wire. The biggest issue was back and forward buttons, even today that issue is not solved very well by SPAs. The issue I have is we had a great idea to refresh parts of a page with AJAX and then we went overboard and tried to move the entire application to complex frameworks which add more problems then they solve. We became so scared of screen rendering we avoided at all costs. This is bad UX as users actually get good confirmation that something has happened when there is a screen refresh.
marginalia_nu 4y ago
All code, across all paradigms, frontend, backend, low level, high level, whatever; all code becomes really messy when you have complex state management. The solution in each of these cases is the same, though. To simplify the state. In general, I think a lot of the pain in web development comes from attempting to have shared mutable state between backend and frontend. Shared mutable states are almost always messy. You can get around that by pushing it all to the frontend, or pushing it all to the backend. It's when it's straddling both you're in for a headache.
- moonchrome 4y ago
  I agree - but you can't simplify when your tools complicate - in the sense that they intertwine different concerns. As soon as you're not dealing with trivial apps "pushing it all to backend" isn't really an option if you want good user experience - and then you'll have to have logic on frontend as well. And that's where the pain comes.

hsbauauvhabzb 4y ago

You only need what’s appropriate. I doubt missile launch systems are using react or whatever fancy frontend engineers want to use. SPAs are responsive which is nice, but some projects could better spend their time ensuring the project actually functions.

hawkeyedan 4y ago
Sadly, that might not be a great bet. The world of government software procurement is very, very ugly.

mxmxnxor 4y ago

>Rendering HTML server-side is just nice No, rendering html server-side is not nice and never was. Why on earth you will send markup template for every list item over and over again instead of sending just data and only one code-template (to render data on a client) ? Suppose you need to show to user a list of books on your web-page. Server side rendering means you need to send to user a markup consists of html elements for every book <div> <div class="book"> <div class="book-title">Book 1</div> <div class="book-author">Author 1</div> <div class="book-description">..description..</div> </div> <div class="book"> <div class="book-title">Book 2</div> <div class="book-author">Author 1</div> <div class="book-description">..description..</div> </div> <div class="book"> <div class="book-title">Book 2</div> <div class="book-author">Author 2</div> <div class="book-description">..description..</div> </div> </div> ... Don't you see something wrong with this? Why you need to duplicate over and over again html template for every list item resulting of significant increase of size of page to download if you can send only one template-component like this <div> <div class="book"> <div class="book-title">{book.title}</div> <div class="book-author">{book.author}</div> <div class="book-description">{book.description}</div> </div> </div> and a data in a more compact way [{title: "Book 1", author: "Author 1", description: "..."}, {title: "Book 1", author: "Author 1", description: "..."}, ...] or more compact like this [["Book 1", "Author 1", "..."],["Book 1", "Author 1", "..."], ...] or even in more compact binary-encoded format resulting in more than magnitude size compaction comparing to over-duplication html-approach. More size means more traffic for users to download over network and users which use data-roaming will "thank" you for your hundreds of kilobytes instead of dozens This is why server-side rendering approach was flawed from the beginning (not because of page reloading but because of data duplication and traffic consumption)

inb4_cancelled 4y ago
Two words: HTTP compression
- louissan 4y ago
  a third word: DIVitis. but yeah, gzip or the more recent ones such as brotli have been taking care of those things for 25 years.... so HTML server-side has always been nice. Especially semantic markup cough cough

mmcnl 4y ago

Rendering server-side HTML is fine, as long as your application is stateless. Then it's really easy. However, when your application becomes more interactive and thus state-driven, is it really easier to it server-side? Remember, the primary function of modern frameworks is to have a declarative way of creating your by writing it as a function of state. Things get messy really quickly once you start to build something more complex. Also, is it really easier to everything on the server? I don't think it is so by definition. You could argue that a stateless REST API with client-side state management is less complex than doing everything server-side. It's a much more scalable solution and creating interactive user interfaces is very easy. Ofcourse it could be that interactive user interfaces is not something you are aiming for. That's fine. But do understand that most applications are actually usually very interactive.

mattmanser 4y ago
Yes, it is. That's what databases and POST data is for and it's all incredibly quick. Almost all applications that are written in the world today are glorified forms. That's reality because 95% of apps are written for the business world. Most don't really do much apart from take some form data, apply business logic to it and show the results/send some messages. Even most consumer apps like Facebook/Twitter/TikTok/Pintrest/etc. are basically glorified forms. You can do save/load state all in nanoseconds, any competent programmer can easily aim for 50ms page loads, well under human detection. This is incredibly basic stuff and how it was done for decades before SPAs.
- feoren 4y ago
  You have rose-colored classes for the past. Multiple-megabyte state cookies were very common in business applications written in .NET WebForms, because even simple CRUD business applications have a lot of state to carry around that nowadays is simply managed in-memory by JavaScript. 50ms load times were out of the question; you were lucky if you could do it in 500ms. No "competent programmer" could do anything about this because WebForms didn't let them. As soon as you needed to filter one dropdown based on another dropdown, you needed to write custom JavaScript anyway. Writing a stateful front-end that just asks for what it needs from a well-built API when it needs it is enormously simpler than trying to store all state in some server session and having to work around your own framework whenever you need a dynamic dropdown list. We all seem to have collectively forgotten how awful web frameworks used to be, and how little interactivity the user actually expected. Things are way better now.

sanderjd 4y ago

Of the people I know who hold this view I know many software developers and zero other people. Even other very technical people, like data scientists, prefer an interactive interface to a series of pages.

gamblor956 4y ago
Of the people I know, ranging from programmers to HR people, most of them prefer the series of pages over the interactive interface for business processes. The series of pages makes it obvious that something has happened in response to input. OTOH, for stuff like Facebook they absolutely prefer the interactive interface.
- sanderjd 4y ago
  The business people I know would mostly rather just do their business processes in Excel rather than a web browser :)
zhte415 4y ago
Almost everyone I know likes to have an expected response when pressing a button. In fact, I don't know anyone that doesn't.
- sanderjd 4y ago
  This seems like an orthogonal question? I agree that whatever technology one chooses, buttons should be responsive when pressed. A page load is not the only kind of button press response that is possible.

bsder 4y ago

> Rendering HTML server-side is just nice. It's simple and easy to work with. Weird states are unusual. The user gets a really normalized, predictable experience. And done well/quickly, there's little actual difference. It has also been forgotten that people used to complain about 100ms of latency. Since then, modern users (especially mobile) have been trained to accept horrible latencies that would have gotten you excoriated back in 2000. 100ms of latency is MUCH more difficult to deal with server side than 2-3 seconds of latency. 2-3 seconds is an eternity with modern clouds and modern network connections.