4 ms·

Not using javascript is not a terrible move by default. In fact, I can think of many cases where it would drastically simplify things. A stateless resource mo

Not using javascript is not a terrible move by default. In fact, I can think of many cases where it would drastically simplify things. A stateless resource model with a distinct separation of concerns and components, that operates in a non-CPU-intensive fashion, can make life much easier on your designers and testers. When serving things like content and straightforward CRUD, your architecture can be made much simpler.

hhsnopek 10y ago
Right so in reality this works for small applications that have a decent amount of traffic, but your site will soon crumble under the server side rendering of things and you might have to spin up more servers to handle the load. You're implementation is perfect for personal blogs and small applications, but at scale it's going to turn into a hassle of managing the monkey patches and scaling issues while still keeping the solid performance you began at.
- binarymax 10y ago
  You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN renders everything on the server (in a dialect of Lisp!) and it's a pretty small cluster that is supporting more users than most webapps dream of.
  - gedrap 10y ago
    Totally. I see this argument about offloading the load to the client so often, that I am left thinking whether I am the only one here working on a project with less than a few thousands of requests every second :) It's good to have performance and scalability in mind but so often it just doesn't matter.
  - hhsnopek 10y ago
    My justification is that not everyone will implement the scaling properly - we do have a lot of server-side apps that properly scale, but depending on the operation it seems the client-side is a better suited pattern
    - binarymax 10y ago
      Straw man. Using a client side approach does not automagically grant you scalability.
      - tremon 10y ago
        Indeed. It does allow you to offload the scalability problems to your users though, and they won't easily tie the draining of their batteries to your site/app.
      - hhsnopek 10y ago
        You're correct, as it does not grant scalability. Tho if my application lives on the client-side, I can distribute the cached application which contains all the user needs. This provides less worry when my server crashes and will still allow my users to access and use my site. Tho will fail if my API's are not accessible. Which then comes down to identifying and breaking the bottleneck. CDN's can also help with my scaling as I can just distribute the bundled up version and live beyond internet access so long as I've built application to be progressive (https://developers.google.com/web/progressive-web-apps https://developers.google.com/web/progressive-web-apps) I can now just notify my application to update next time the user connects to the internet. Tho if my application where to only live with the server rendering my information, I wouldn't be able to periodically lose my "stable" connection and my application would be rendered useless. Tho this solution is adaptable to server-side applications, you'll need to use javascript to do so. And I believe that settles why we need javascript in your applications. If I can't access your sever-side application because it's flooded with requests and the cached version of your site relies on the server then I believe you've failed your users. The solution to scalability for both server-side and client-side applications are complex, but only one of them depends on a server being around while the other relies on a cached copy.
  - deleted 10y ago
    [deleted]
- smadge 10y ago
  Let's think in orders of magnitude here. Will moving template rendering from the client to the server increase server load by an order of magnitude? I might be wrong here, but if more than half your request is spent in a templating engine, something is seriously wrong. Moving your code to the client side seems like an incredibly lazy way to shave a few milliseconds off your request time. Not to mention your doing so at the expense of increasing initial page load for the user, and breaking the semantic web.
- bobwaycott 10y ago
  So, instead of tackling and solving performance issues with a known resource (your server hardware), the situation is improved by "solving" performance issues/concerns by dumping them on an unknown resource (your users' hardware)? That sounds like an awfully foolish argument and approach to me.
ramy_d 10y ago
I think its a great idea to consider, a fresh perspective, especially when you consider how slow some sites can become for mobile users. Offloading trivial JS to the server and leveraging CSS/HTML, which would be better optimized on those devices, could be something to look into. Especially when you consider how slow some sites get on mobile just because of the JS they run. I'd like to see a trivial app implemented in JS and then re-implemented using Dala's method.

hhsnopek 10y ago

Right so in reality this works for small applications that have a decent amount of traffic, but your site will soon crumble under the server side rendering of things and you might have to spin up more servers to handle the load. You're implementation is perfect for personal blogs and small applications, but at scale it's going to turn into a hassle of managing the monkey patches and scaling issues while still keeping the solid performance you began at.

binarymax 10y ago
You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN renders everything on the server (in a dialect of Lisp!) and it's a pretty small cluster that is supporting more users than most webapps dream of.
- gedrap 10y ago
  Totally. I see this argument about offloading the load to the client so often, that I am left thinking whether I am the only one here working on a project with less than a few thousands of requests every second :) It's good to have performance and scalability in mind but so often it just doesn't matter.
- hhsnopek 10y ago
  My justification is that not everyone will implement the scaling properly - we do have a lot of server-side apps that properly scale, but depending on the operation it seems the client-side is a better suited pattern
  - binarymax 10y ago
    Straw man. Using a client side approach does not automagically grant you scalability.
    - tremon 10y ago
      Indeed. It does allow you to offload the scalability problems to your users though, and they won't easily tie the draining of their batteries to your site/app.
    - hhsnopek 10y ago
      You're correct, as it does not grant scalability. Tho if my application lives on the client-side, I can distribute the cached application which contains all the user needs. This provides less worry when my server crashes and will still allow my users to access and use my site. Tho will fail if my API's are not accessible. Which then comes down to identifying and breaking the bottleneck. CDN's can also help with my scaling as I can just distribute the bundled up version and live beyond internet access so long as I've built application to be progressive (https://developers.google.com/web/progressive-web-apps https://developers.google.com/web/progressive-web-apps) I can now just notify my application to update next time the user connects to the internet. Tho if my application where to only live with the server rendering my information, I wouldn't be able to periodically lose my "stable" connection and my application would be rendered useless. Tho this solution is adaptable to server-side applications, you'll need to use javascript to do so. And I believe that settles why we need javascript in your applications. If I can't access your sever-side application because it's flooded with requests and the cached version of your site relies on the server then I believe you've failed your users. The solution to scalability for both server-side and client-side applications are complex, but only one of them depends on a server being around while the other relies on a cached copy.
- deleted 10y ago
  [deleted]
smadge 10y ago
Let's think in orders of magnitude here. Will moving template rendering from the client to the server increase server load by an order of magnitude? I might be wrong here, but if more than half your request is spent in a templating engine, something is seriously wrong. Moving your code to the client side seems like an incredibly lazy way to shave a few milliseconds off your request time. Not to mention your doing so at the expense of increasing initial page load for the user, and breaking the semantic web.
bobwaycott 10y ago
So, instead of tackling and solving performance issues with a known resource (your server hardware), the situation is improved by "solving" performance issues/concerns by dumping them on an unknown resource (your users' hardware)? That sounds like an awfully foolish argument and approach to me.

ramy_d 10y ago

I think its a great idea to consider, a fresh perspective, especially when you consider how slow some sites can become for mobile users. Offloading trivial JS to the server and leveraging CSS/HTML, which would be better optimized on those devices, could be something to look into. Especially when you consider how slow some sites get on mobile just because of the JS they run. I'd like to see a trivial app implemented in JS and then re-implemented using Dala's method.