7 ms·

I am of the opinion that there is no longer a need for server side templating languages and that they only serve to complicate the technology stack. With REST s

by kls 16y ago

I am of the opinion that there is no longer a need for server side templating languages and that they only serve to complicate the technology stack. With REST services, Javascript, CSS and HTML the technology stack for web development has become significantly simplified due to the fact that it is once again digestible. A designer can know HTML and CSS and provide designer services without having to know the intricacies of a back end technology (many times several) further they can graduate into JavaScript UI programming as they grow and gain experience. Finally they can grow into developing back end services. With modern web development the layers have become compartmentalized or black boxed to shield each layer from the implementation details of the others. This is a good thing because a new developer does not have to master "technology soup" to become the lowest level of proficient. With current trends in web development, server side UI frameworks make no sense. The take a longer development cycle and they produce inferior results.

olalonde 16y ago
I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.
- pilif 16y ago
  Google parses and executes JavaScript already. http://code.google.com/web/ajaxcrawling/docs/getting-started.html http://code.google.com/web/ajaxcrawling/docs/getting-started... that's where that exclamation mark in the hash of the URL in recent sites comes from (like new twitter) Edit: Look at this query: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=site:tempalias.com+prune http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... it finds the existence of that word on my privacy page that gets only loaded via AJAX. So it must be able execute the javascript (sammy, basically) that intercepts these links to load the correct page fragment. Edit: Explanation is wrong. It takes a little bit of server side magic to work. See comment below. I completely forgot about this after implementing it in April :-)
  - simonw 16y ago
    Their Ajax crawling stuff doesn't work by executing JavaScript within their crawler. If you read the docs you linked to, they specify that this URL: http://tempalias.com/#!/privacy http://tempalias.com/#!/privacy Gets converted by their crawler in to this: http://tempalias.com/?_escaped_fragment_=/privacy http://tempalias.com/?_escaped_fragment_=/privacy It's up to you to implement your server-side code such that ?_escaped_fragment_ causes an indexable version of your content to be served up.
    - pilif 16y ago
      Of course you are right. It has been a while since I've done this. Sorry for the confusion. I totally forgot that :-)
- simonw 16y ago
  I won't. The web for me is URLs and HTML. JavaScript is for providing user experience enhancements on top of that. I don't want a Web which can only be understood by running a JavaScript interpreter against it.
  - deleted 16y ago
    [deleted]
  - dasil003 16y ago
    I used to agree, but now I actually think there are two webs. There is the original web, the document web, but there is also the application web. Sometimes the two overlap, and almost every site has at least some documents that should be plain ol' HTML. However in working on the application web for the last 5 years I've come to appreciate the power of new approaches for web-based user applications. It turns out that generating full HTML pages for users can turn into an incredible waste of resources and significantly worse UX, for what amounts to a very tiny accessibility and SEO advantage. Facebook is the canonical example here. The way they load a page is brilliant from a UX and server resource perspective. But consider apps that are much less dynamic. Say you have a 50k page with 1k of dynamic content per user or some other variable such as country. Page caching is impossible. You can rig up all kinds of complex server side fragment caching mechanisms, and squeeze quite a bit of performance out. However these schemes quickly grow very complex, whereas the client/server architecture lends itself to a solution that is orders of magnitude more elegant, which is simply to load the dynamic bits via AJAX. This A) offloads processing to the client, B) solves all kinds of caching problems, allowing full HTTP caching where it would have been impossible, and bypasses hordes of thorny cache invalidation problems, C) creates some elegant optimizations that would have chicken-or-egg problems if attempted on a server-side MVC architecture alone, D) Improves page responsiveness dramatically as the initial HTML shell and static assets can start loading almost instantaneously, and E) allows a more de-coupled architecture that makes sharding and scaling much easier. Because of the technical advantages, it's inevitable that web-based app development will continue moving in this direction. Web apps that don't go in this direction will be at a disadvantage from an operating cost and UX perspective.
- neilk 16y ago
  Nothing about the idea requires abandoning HTML for content. However, something like login management could be completely handled by an API. So the browser would be combining different sources of HTML into once package. This is pretty much what is happening with the Facebook "Like" button anyway. There are a lot of sites out there which serve pages which are mostly static content with just a little bit extra -- the login name at the top, personalized tools here and there. I happen to work with Wikipedia content, so that's top of my mind right now. If you are logged in, we give you content rendered mostly from scratch, since the caching system is optimized for the non-logged-in user and there are user preferences which might transform the content in complicated ways. (Even things like date formats are subject to user preferences, so it's considerably harder to cache). This works okay, but it's dramatically more expensive for logged in users. We would have to rethink things if we ever got to a world where a lot more people are logged in. A paradigm I'd like to explore would be to fetch the static content from one set of servers, and login state and personal options and other transformations from another, and get the browser to combine it all. Probably won't ever happen on Wikipedia though, at least not soon.
- percept 16y ago
  "Sites" vs. "apps."
pilif 16y ago
agreed. My first bigger node project (http://tempalias.com http://tempalias.com) works without generating even a single byte of HTML dynamically on the server. It's all plain HTML and JavaScript statically served and talking to the server via a REST API. This way I don't have to "bolt on" an API that might be incomplete. Instead, the frontend uses exactly the same API as any prospective client would. When I started the thing, I was using the Express framework, but soon began to feel exactly like the original poster. Express was porting Rails to Node and I wanted something else. Hence I moved to paperboy to serve the static files and did the (simple!) API on my own - plugging paperboy into an existing node server with existing endpoints is incredibly easy (or I could serve the static files directly, but I wanted the code to work without external dependencies to help the community to get a service of their own to run). If you are interested in the development (tempalias is MIT licensed and available at github), I would recommend you either the development journal (http://www.gnegg.ch/tag/tempalias http://www.gnegg.ch/tag/tempalias) or the talk I gave at jsconf.eu (http://bit.ly/b4gsrL http://bit.ly/b4gsrL)
- kls 16y ago
  Thanks for the reply, my next project is going to be doing the REST services with Node. I have been using Java for my services because until Node I really did not see a big enough reason to move platforms. What are you using for your REST services implementation, a Node library or did you roll your own? I did not know about Paperboy so thanks for pointing me to that project.
  - pilif 16y ago
    in this case, the API was so simple, I could easily roll my own (it's not even a real framework - I have one resource, the alias and I allow basically just POST to /aliases to create one at the moment). The beauty about node is that it's so simple to extend and add the functionality you need. No magic, no huge framework to learn. The little things you get though work awesomely well and are a pleasure to use.
    - kls 16y ago
swah 16y ago
Your ideas since this (http://news.ycombinator.com/item?id=898947 http://news.ycombinator.com/item?id=898947) have been an eye opener to me. Definitely this just seems to make most parts easier and more testable and more distributed. I'm thinking how the several parts web frameworks implement would work in the "Client/server 2.0" model. One of the parts I can't quite figure, probably because frameworks like Django hide it completely, is how would we implement sessions. I'm thinking about the user closing a page, then reopening and wanting to see their cart there, for example. I'd love you if gave me more links to read to understand how I could implement this. I'm starting to write code for my startup and this model seems a perfect fit.
- kls 16y ago
  There are two schools of thought on session. On is that it should be avoided at all cost and believe that it is an ant-pattern The web was designed to be a stateless medium and session introduces state. Which causes all kinds of problems on a platform that was designed to be stateless. While I agree with the line of reasoning, I consider myself pragmatic and therefore subscribe to the second school of though which is session should be guarded. Our system throws warning flags whenever someone checks in new code that uses session, it is then flagged for review. We tend to try to build our services stateless by passing the relevant information needed to complete a transaction. You could think of the communication like this: one could be represented as a telephone call, where you have to have the context of previous messages to understand the communication (stateful), while the other could be though of like voice mails where the entire context of the communication is transmitted as a complete package. We tend to try to design our services like the latter but some times it is not practical due to sensitive information or other concerns. This is where session comes into play. So for us, how we build out services is that we generate an identity token (based on SAML), that token represents the users (authentication and authorization). Further we store any global information that is not sensitive in a cookie that way they can be passes with the context of the communication to make a full stateless call to a service. Finally, if there is a special case, that requires performance we will place that information in session for a user, we find that these cases are rarer than one would expect. I am working on a blog: http://www.httparchitect.com http://www.httparchitect.com it is by no means ready for prime time, but if you want to check it out it does have links to reference material. My next article was actually going to be on session management and statelessness.
bad_user 16y ago
> I am of the opinion that there is no longer a need for server side templating languages This makes the assumption that all apps are dumb frontends to a database.
- thomas11 16y ago
  Why? You can have arbitrarily complex logic and computation in client-side JavaScript. Whether it's a good idea is another question.
- kls 16y ago
  No it makes the assumption that UI logic provides the best user experience when it is closest to the UI. Services can provide any form of calculation logic that one needs them too. UI logic is removed from the server and placed with the UI while business logic and data services remain with the business systems.
- toddheasley 16y ago
  > This makes the assumption that all apps are dumb frontends to a database. I think the commenter is talking specifically about templating languages, not all server-side logic. In terms of MVC, I think the idea is that now you can move the entire view layer to the client, rather than doing half on the server and half in JavaScript.
  - kls 16y ago
    Right, my point was that templating was a concern of the UI, yet I wanted to be clear that business logic and data services remain the domain of the application server. Further I try to remove templating from any run-time concern (server or client) by doing all static content templating in a CMS and then publishing it to a web server.
    - bad_user 16y ago
      OK, sorry, I misunderstood your point. Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines). But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.
deleted 16y ago
[deleted]

by kls 16y ago

olalonde 16y ago

I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.

pilif 16y ago
Google parses and executes JavaScript already. http://code.google.com/web/ajaxcrawling/docs/getting-started.html http://code.google.com/web/ajaxcrawling/docs/getting-started... that's where that exclamation mark in the hash of the URL in recent sites comes from (like new twitter) Edit: Look at this query: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=site:tempalias.com+prune http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... it finds the existence of that word on my privacy page that gets only loaded via AJAX. So it must be able execute the javascript (sammy, basically) that intercepts these links to load the correct page fragment. Edit: Explanation is wrong. It takes a little bit of server side magic to work. See comment below. I completely forgot about this after implementing it in April :-)
- simonw 16y ago
  Their Ajax crawling stuff doesn't work by executing JavaScript within their crawler. If you read the docs you linked to, they specify that this URL: http://tempalias.com/#!/privacy http://tempalias.com/#!/privacy Gets converted by their crawler in to this: http://tempalias.com/?_escaped_fragment_=/privacy http://tempalias.com/?_escaped_fragment_=/privacy It's up to you to implement your server-side code such that ?_escaped_fragment_ causes an indexable version of your content to be served up.
  - pilif 16y ago
    Of course you are right. It has been a while since I've done this. Sorry for the confusion. I totally forgot that :-)
simonw 16y ago
I won't. The web for me is URLs and HTML. JavaScript is for providing user experience enhancements on top of that. I don't want a Web which can only be understood by running a JavaScript interpreter against it.
- deleted 16y ago
  [deleted]
- dasil003 16y ago
  I used to agree, but now I actually think there are two webs. There is the original web, the document web, but there is also the application web. Sometimes the two overlap, and almost every site has at least some documents that should be plain ol' HTML. However in working on the application web for the last 5 years I've come to appreciate the power of new approaches for web-based user applications. It turns out that generating full HTML pages for users can turn into an incredible waste of resources and significantly worse UX, for what amounts to a very tiny accessibility and SEO advantage. Facebook is the canonical example here. The way they load a page is brilliant from a UX and server resource perspective. But consider apps that are much less dynamic. Say you have a 50k page with 1k of dynamic content per user or some other variable such as country. Page caching is impossible. You can rig up all kinds of complex server side fragment caching mechanisms, and squeeze quite a bit of performance out. However these schemes quickly grow very complex, whereas the client/server architecture lends itself to a solution that is orders of magnitude more elegant, which is simply to load the dynamic bits via AJAX. This A) offloads processing to the client, B) solves all kinds of caching problems, allowing full HTTP caching where it would have been impossible, and bypasses hordes of thorny cache invalidation problems, C) creates some elegant optimizations that would have chicken-or-egg problems if attempted on a server-side MVC architecture alone, D) Improves page responsiveness dramatically as the initial HTML shell and static assets can start loading almost instantaneously, and E) allows a more de-coupled architecture that makes sharding and scaling much easier. Because of the technical advantages, it's inevitable that web-based app development will continue moving in this direction. Web apps that don't go in this direction will be at a disadvantage from an operating cost and UX perspective.
neilk 16y ago
Nothing about the idea requires abandoning HTML for content. However, something like login management could be completely handled by an API. So the browser would be combining different sources of HTML into once package. This is pretty much what is happening with the Facebook "Like" button anyway. There are a lot of sites out there which serve pages which are mostly static content with just a little bit extra -- the login name at the top, personalized tools here and there. I happen to work with Wikipedia content, so that's top of my mind right now. If you are logged in, we give you content rendered mostly from scratch, since the caching system is optimized for the non-logged-in user and there are user preferences which might transform the content in complicated ways. (Even things like date formats are subject to user preferences, so it's considerably harder to cache). This works okay, but it's dramatically more expensive for logged in users. We would have to rethink things if we ever got to a world where a lot more people are logged in. A paradigm I'd like to explore would be to fetch the static content from one set of servers, and login state and personal options and other transformations from another, and get the browser to combine it all. Probably won't ever happen on Wikipedia though, at least not soon.
percept 16y ago
"Sites" vs. "apps."

pilif 16y ago

agreed. My first bigger node project (http://tempalias.com http://tempalias.com) works without generating even a single byte of HTML dynamically on the server. It's all plain HTML and JavaScript statically served and talking to the server via a REST API. This way I don't have to "bolt on" an API that might be incomplete. Instead, the frontend uses exactly the same API as any prospective client would. When I started the thing, I was using the Express framework, but soon began to feel exactly like the original poster. Express was porting Rails to Node and I wanted something else. Hence I moved to paperboy to serve the static files and did the (simple!) API on my own - plugging paperboy into an existing node server with existing endpoints is incredibly easy (or I could serve the static files directly, but I wanted the code to work without external dependencies to help the community to get a service of their own to run). If you are interested in the development (tempalias is MIT licensed and available at github), I would recommend you either the development journal (http://www.gnegg.ch/tag/tempalias http://www.gnegg.ch/tag/tempalias) or the talk I gave at jsconf.eu (http://bit.ly/b4gsrL http://bit.ly/b4gsrL)

kls 16y ago
Thanks for the reply, my next project is going to be doing the REST services with Node. I have been using Java for my services because until Node I really did not see a big enough reason to move platforms. What are you using for your REST services implementation, a Node library or did you roll your own? I did not know about Paperboy so thanks for pointing me to that project.
- pilif 16y ago
  in this case, the API was so simple, I could easily roll my own (it's not even a real framework - I have one resource, the alias and I allow basically just POST to /aliases to create one at the moment). The beauty about node is that it's so simple to extend and add the functionality you need. No magic, no huge framework to learn. The little things you get though work awesomely well and are a pleasure to use.
  - kls 16y ago

swah 16y ago

Your ideas since this (http://news.ycombinator.com/item?id=898947 http://news.ycombinator.com/item?id=898947) have been an eye opener to me. Definitely this just seems to make most parts easier and more testable and more distributed. I'm thinking how the several parts web frameworks implement would work in the "Client/server 2.0" model. One of the parts I can't quite figure, probably because frameworks like Django hide it completely, is how would we implement sessions. I'm thinking about the user closing a page, then reopening and wanting to see their cart there, for example. I'd love you if gave me more links to read to understand how I could implement this. I'm starting to write code for my startup and this model seems a perfect fit.

kls 16y ago
There are two schools of thought on session. On is that it should be avoided at all cost and believe that it is an ant-pattern The web was designed to be a stateless medium and session introduces state. Which causes all kinds of problems on a platform that was designed to be stateless. While I agree with the line of reasoning, I consider myself pragmatic and therefore subscribe to the second school of though which is session should be guarded. Our system throws warning flags whenever someone checks in new code that uses session, it is then flagged for review. We tend to try to build our services stateless by passing the relevant information needed to complete a transaction. You could think of the communication like this: one could be represented as a telephone call, where you have to have the context of previous messages to understand the communication (stateful), while the other could be though of like voice mails where the entire context of the communication is transmitted as a complete package. We tend to try to design our services like the latter but some times it is not practical due to sensitive information or other concerns. This is where session comes into play. So for us, how we build out services is that we generate an identity token (based on SAML), that token represents the users (authentication and authorization). Further we store any global information that is not sensitive in a cookie that way they can be passes with the context of the communication to make a full stateless call to a service. Finally, if there is a special case, that requires performance we will place that information in session for a user, we find that these cases are rarer than one would expect. I am working on a blog: http://www.httparchitect.com http://www.httparchitect.com it is by no means ready for prime time, but if you want to check it out it does have links to reference material. My next article was actually going to be on session management and statelessness.

bad_user 16y ago

> I am of the opinion that there is no longer a need for server side templating languages This makes the assumption that all apps are dumb frontends to a database.

thomas11 16y ago
Why? You can have arbitrarily complex logic and computation in client-side JavaScript. Whether it's a good idea is another question.
kls 16y ago
No it makes the assumption that UI logic provides the best user experience when it is closest to the UI. Services can provide any form of calculation logic that one needs them too. UI logic is removed from the server and placed with the UI while business logic and data services remain with the business systems.
toddheasley 16y ago
> This makes the assumption that all apps are dumb frontends to a database. I think the commenter is talking specifically about templating languages, not all server-side logic. In terms of MVC, I think the idea is that now you can move the entire view layer to the client, rather than doing half on the server and half in JavaScript.
- kls 16y ago
  Right, my point was that templating was a concern of the UI, yet I wanted to be clear that business logic and data services remain the domain of the application server. Further I try to remove templating from any run-time concern (server or client) by doing all static content templating in a CMS and then publishing it to a web server.
  - bad_user 16y ago
    OK, sorry, I misunderstood your point. Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines). But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.

deleted 16y ago

[deleted]