6 ms·

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of ja

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top? When I need a more dynamic page, I create a react app specifically for this one page. Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).

andybak 8y ago
No. You're not the only one.
draw_down 8y ago
Easy there tiger, React and others are compatible with server side rendering. They’re capable of being the “little bit of JS” on top. Everything will be ok.
- aaronmu 8y ago
  I am well aware of server side rendering but you still need to send all that javascript to the client, whether it ran on the server or not. Wouldn't exactly call this a "little bit of js" on top :p
- filleduchaos 8y ago
  Let's see - one could have both server and client jumping through hoops rendering a client-side framework on the server and then hydrating it again on the client (including having to pull in all the tooling that would require)...or one could just use regular old templates. There certainly is nothing wrong with going with simplicity over a solution that's overengineered for one's case, tiger.
- jackfraser 8y ago
  I was a web dev in a previous lifetime and have gone to the backend for almost a decade now; one of these days I need to climb back up again. Threads like this one are intimidating in a way because there's just been So Much Development and everything I knew was wrong, except... it also still all works just fine! It's just the incorrect way of doing things now. It's good to hear that maybe when the time comes, I can dip into React by using it as the sprinkle of JS that jQuery / jqxWidgets and such were for me the last time I did any of this.
IloveHN84 8y ago
You're not alone. Frameworks favour vendor-lockins, better avoid those ones, if they get abandoned or iterate too fast (see React)
cjblomqvist 8y ago
In my experience, the problem with a lot of those solutions is that at some point you still need to handle data and some significant dynamic content. Of course, this depends on what you do, but even a simple e-commerce site is fairly dynamic nowadays. What happens if you go the I'll-do-it-myself is that you still get a significant amount of code, and lots more bugs since you'll have to redevelop significant pieces of what the libraries and frameworks already have done (and tested) - and you'll ever be better than them. Of course, you don't need to use Javascript to render your whole page. You can still use React or Vue to add these dynamic parts, and render the rest at the backend. Imo this might be one of the most underrated ways of doing things. I guess human tend to go to the extremes without being rational about it necessarily (or thinking for themselves and just buying into the hype).
- aaronmu 8y ago
  I totally agree with you! I've used react and redux in almost every project last year, but that doesn't mean the entire web app was written using react and redux. 50 ~80% was plain old static content rendered on the server. A dynamic client side UI is more expensive to build compared to static html rendered on the server. Our software usually aims to solve a business problem for as little money as possible so we only build these dynamic ui's when they're absolutely required.
- h1d 8y ago
  It's funny that some of these client side framework is wrecking the pages as if things are worse than 10 years ago from users' point of view. I visit a major credit card company's account page and it shows the last time I visited as 'undefined' for a second until it grabs the data to render and it just looks shit. And I also don't like seeing the page loaded with minimal placeholder, only having have to wait a few seconds for the page to finally render, which is more annoying than even waiting on a blank page because you can't easily tell if things are all loaded or not with placeholders all over. A pure bad example of over engineering. You need to make sure things don't look shit using client side framework.
virtualwhys 8y ago
For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence. Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed. Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources? A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue. There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.
- peteforde 8y ago
  I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus. https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks https://stimulusjs.org/ https://stimulusjs.org/ You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.
  - pklee 8y ago
    Just looked at stimulus. Really cool framework. circa 2008 or so there was this concept of non-intrusive javascript where you bind js to elements. So you could wysiwyg html and then inject js where you need it. Thought that was a neat idea and like what stimulus does it. Any real life experience from anyone ?
    - TomK32 8y ago
      Yes, I'm using it in the budgeting webapp that I develop and here's one little component that I shared, a calculator for input boxes https://tomk32.de/2018/08/04/stimulus-component-calculator.html https://tomk32.de/2018/08/04/stimulus-component-calculator.h... Really should add a gif or something.
pjmlp 8y ago
Not at all, as I replied on another thread. Plain old Java and .NET frameworks or CMS, with server side rendering, with dynamic behaviour on as needed basis.
stephenr 8y ago
I found the entire premise of the question weird - s/he asks about what people are using, and then states s/he wants to use two specific things. "Waiter, what can you suggest for me, I want to eat a fillet mignon?". As for your view - I agree mostly. I'm definitely in favour of making things entirely in the 'classic' web model, adding javascript to enhance things where it makes sense (some of this now is just polyfilling html5 form controls where they're not native).
romanovcode 8y ago
Nope, I would not use SPA unless it's certainly necessary. If client wants the "SPA Effect" you can just slap Turbolinks and be done.
Lord_Zero 8y ago
At my work we need APIs for integrations. The easiest path for us is to write the API and write an app to consume it. Although I suppose you could do the extra work to bundle a UI with the API and share the business logic. Also dog fooding helps us get the API right the first time. Im not 100% into the SPA world, in fact one of our clients is an MVC app which uses a mix of HttpClient to call our API and good old fashioned jQuery AJAX calls. I just wanted to voice this and say if you live in a world where people do not need to integrate with your API then a regular MVC style app and little to no JS is fine. Also, JS helps when you need to do things like CRUD many-to-many relationships on your UI without a bunch of postbacks.

andybak 8y ago

No. You're not the only one.

draw_down 8y ago

Easy there tiger, React and others are compatible with server side rendering. They’re capable of being the “little bit of JS” on top. Everything will be ok.

aaronmu 8y ago
I am well aware of server side rendering but you still need to send all that javascript to the client, whether it ran on the server or not. Wouldn't exactly call this a "little bit of js" on top :p
filleduchaos 8y ago
Let's see - one could have both server and client jumping through hoops rendering a client-side framework on the server and then hydrating it again on the client (including having to pull in all the tooling that would require)...or one could just use regular old templates. There certainly is nothing wrong with going with simplicity over a solution that's overengineered for one's case, tiger.
jackfraser 8y ago
I was a web dev in a previous lifetime and have gone to the backend for almost a decade now; one of these days I need to climb back up again. Threads like this one are intimidating in a way because there's just been So Much Development and everything I knew was wrong, except... it also still all works just fine! It's just the incorrect way of doing things now. It's good to hear that maybe when the time comes, I can dip into React by using it as the sprinkle of JS that jQuery / jqxWidgets and such were for me the last time I did any of this.

IloveHN84 8y ago

You're not alone. Frameworks favour vendor-lockins, better avoid those ones, if they get abandoned or iterate too fast (see React)

cjblomqvist 8y ago

In my experience, the problem with a lot of those solutions is that at some point you still need to handle data and some significant dynamic content. Of course, this depends on what you do, but even a simple e-commerce site is fairly dynamic nowadays. What happens if you go the I'll-do-it-myself is that you still get a significant amount of code, and lots more bugs since you'll have to redevelop significant pieces of what the libraries and frameworks already have done (and tested) - and you'll ever be better than them. Of course, you don't need to use Javascript to render your whole page. You can still use React or Vue to add these dynamic parts, and render the rest at the backend. Imo this might be one of the most underrated ways of doing things. I guess human tend to go to the extremes without being rational about it necessarily (or thinking for themselves and just buying into the hype).

aaronmu 8y ago
I totally agree with you! I've used react and redux in almost every project last year, but that doesn't mean the entire web app was written using react and redux. 50 ~80% was plain old static content rendered on the server. A dynamic client side UI is more expensive to build compared to static html rendered on the server. Our software usually aims to solve a business problem for as little money as possible so we only build these dynamic ui's when they're absolutely required.
h1d 8y ago
It's funny that some of these client side framework is wrecking the pages as if things are worse than 10 years ago from users' point of view. I visit a major credit card company's account page and it shows the last time I visited as 'undefined' for a second until it grabs the data to render and it just looks shit. And I also don't like seeing the page loaded with minimal placeholder, only having have to wait a few seconds for the page to finally render, which is more annoying than even waiting on a blank page because you can't easily tell if things are all loaded or not with placeholders all over. A pure bad example of over engineering. You need to make sure things don't look shit using client side framework.

virtualwhys 8y ago

For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence. Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed. Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources? A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue. There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.

peteforde 8y ago
I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus. https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks https://stimulusjs.org/ https://stimulusjs.org/ You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.
- pklee 8y ago
  Just looked at stimulus. Really cool framework. circa 2008 or so there was this concept of non-intrusive javascript where you bind js to elements. So you could wysiwyg html and then inject js where you need it. Thought that was a neat idea and like what stimulus does it. Any real life experience from anyone ?
  - TomK32 8y ago
    Yes, I'm using it in the budgeting webapp that I develop and here's one little component that I shared, a calculator for input boxes https://tomk32.de/2018/08/04/stimulus-component-calculator.html https://tomk32.de/2018/08/04/stimulus-component-calculator.h... Really should add a gif or something.

pjmlp 8y ago

Not at all, as I replied on another thread. Plain old Java and .NET frameworks or CMS, with server side rendering, with dynamic behaviour on as needed basis.

stephenr 8y ago

I found the entire premise of the question weird - s/he asks about what people are using, and then states s/he wants to use two specific things. "Waiter, what can you suggest for me, I want to eat a fillet mignon?". As for your view - I agree mostly. I'm definitely in favour of making things entirely in the 'classic' web model, adding javascript to enhance things where it makes sense (some of this now is just polyfilling html5 form controls where they're not native).

romanovcode 8y ago

Nope, I would not use SPA unless it's certainly necessary. If client wants the "SPA Effect" you can just slap Turbolinks and be done.

Lord_Zero 8y ago

At my work we need APIs for integrations. The easiest path for us is to write the API and write an app to consume it. Although I suppose you could do the extra work to bundle a UI with the API and share the business logic. Also dog fooding helps us get the API right the first time. Im not 100% into the SPA world, in fact one of our clients is an MVC app which uses a mix of HttpClient to call our API and good old fashioned jQuery AJAX calls. I just wanted to voice this and say if you live in a world where people do not need to integrate with your API then a regular MVC style app and little to no JS is fine. Also, JS helps when you need to do things like CRUD many-to-many relationships on your UI without a bunch of postbacks.