4 ms·

(Not using javascript) This is a terrible move, consider this: Your web stack has many moving parts that can be adjusted on both client and server side. Now fr

(Not using javascript) This is a terrible move, consider this: Your web stack has many moving parts that can be adjusted on both client and server side. Now from what I'm getting from the article, all my websites are server side apps. This means I must run a server that I need to factor in scaling and performance. I need to know what my bottleneck is, which will likely end up being what I'm rendering at almost live time. Now consider that we use a client-side application which only lives in the browser and contacts an API to confirm authorization to x, y or z. We not only decreased the load time of the site, but also allow everything to be done on their machine and not my server. My bottleneck becomes the my clientside logic and then the CDN I'm ruining my site thru. Mind you I can now have my CDN cache my site because everything is done on the client. There might be problems and flaws with javascript, but disregarding a language just because of the server side pattern isn't right. I'd like to see some implementations you've done that are better alternatives to using javascript.

binarymax 11y ago
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 11y 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 11y 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 11y 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 11y 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 11y ago
        Straw man. Using a client side approach does not automagically grant you scalability.
        tremon 11y 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 11y 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.
- ramy_d 11y 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.
Roboprog 11y ago
This, minus the CDN - using compression and static file caching headers, only - is how we are handling a major app upgrade (pretty much a rewrite) at work. Of course, I flip flopped from hating Javascript to really liking it about 10 years ago. Now after having done most of my work in JS (plus Angular 1) the last year, I can't stand working in Java any more. So much blah blah blah to do anything on the server (since Java is mandated). I'll save the Java rant for another day. Personally, I find that maintaining state about "workflow" in an actual data entry app is MUCH easier in a fat client than trying to preserve state while entire pages bounce back and forth between client and server. Webflows (Spring/JSF)? Therein lies madness... And it is pretty cool that our server app has simply became a pile of REST services with default client app resources bundled in. We already prototyped an integration with another system a few months ago that demoed very well.
- PaulHoule 11y ago
  Sometimes CDNs seem like a scam to me. I have been building "insanely fast" apps based on HTTP/2 and everything local. My experience is that every DNS lookup you add is a chance for somebody's web browser to go out to lunch for an unbounded interval. (Back when we got DSL in my neck of the woods, web browsing often was slower on DSL than dialup because the DNS service was so bad.) As for the back end it is a matter of having a framework that works. Unfortunately Sun, Microsoft and most legacy vendors have a history of hiring systems programmers instead of application programmers to develop frameworks, so the average back end framework is seriously flawed. For instance, Web Forms in .NET were a great idea, but had the fatal flaw that they did not work in an MVC environment where you might want to load a different template depending on the outcome of form processing. Instead of fixing this, they build a new MVC framework that didn't learn from the mistakes of the last framework...
- xellisx 11y ago
  Well 10 years ago, actually just a couple years before is when it started to sprout wings and mature. Long gone are the days of the "Fun Stuff" that you used to be able to do with JS. Thankfully Active Script died.

binarymax 11y ago

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 11y 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 11y 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 11y 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 11y 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 11y ago
      Straw man. Using a client side approach does not automagically grant you scalability.
      - tremon 11y 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 11y 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.
ramy_d 11y 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.

Roboprog 11y ago

This, minus the CDN - using compression and static file caching headers, only - is how we are handling a major app upgrade (pretty much a rewrite) at work. Of course, I flip flopped from hating Javascript to really liking it about 10 years ago. Now after having done most of my work in JS (plus Angular 1) the last year, I can't stand working in Java any more. So much blah blah blah to do anything on the server (since Java is mandated). I'll save the Java rant for another day. Personally, I find that maintaining state about "workflow" in an actual data entry app is MUCH easier in a fat client than trying to preserve state while entire pages bounce back and forth between client and server. Webflows (Spring/JSF)? Therein lies madness... And it is pretty cool that our server app has simply became a pile of REST services with default client app resources bundled in. We already prototyped an integration with another system a few months ago that demoed very well.

PaulHoule 11y ago
Sometimes CDNs seem like a scam to me. I have been building "insanely fast" apps based on HTTP/2 and everything local. My experience is that every DNS lookup you add is a chance for somebody's web browser to go out to lunch for an unbounded interval. (Back when we got DSL in my neck of the woods, web browsing often was slower on DSL than dialup because the DNS service was so bad.) As for the back end it is a matter of having a framework that works. Unfortunately Sun, Microsoft and most legacy vendors have a history of hiring systems programmers instead of application programmers to develop frameworks, so the average back end framework is seriously flawed. For instance, Web Forms in .NET were a great idea, but had the fatal flaw that they did not work in an MVC environment where you might want to load a different template depending on the outcome of form processing. Instead of fixing this, they build a new MVC framework that didn't learn from the mistakes of the last framework...
xellisx 11y ago
Well 10 years ago, actually just a couple years before is when it started to sprout wings and mature. Long gone are the days of the "Fun Stuff" that you used to be able to do with JS. Thankfully Active Script died.