> Note the awesome Shakespearean inspired name convention. Another good reason to use yesod.
Lol.
> Until here I believe it goes in the right direction. Even if I believe the real future is by generating HTML pages from the client (using javascript) and server limited to serve JSON (or XML, or any object representation system).
This is a little unclear. Do you mean, prior to Yesod you thought web development was heading in the right direction, but Yesod made you realize there was a much better way, even if the future is HTML5 rich web apps with the app server as a JSON/XML API endpoint?
Mainly, I believe that most the energy put in Yesod goes on the problem I find the most important.
- Security by default, directly imported from the Haskell type system.
- Fast, also, because Haskell is quite fast compared to most languages used for the web.
- Able to manage a lot of concurrent connexions,
- Incredible foundation language, Haskell is simply awesome (look at my latest blog post for details[^1]).
On the other hand, IMHO, the future of the web might be:
- an API server as good as possible (fast/distributed/clever)
- many good quality dynamic (and generally native) clients
Therefore, I find most of the effort put in the HTML/CSS/JS generation while impressive not so essential for what I look.
On the other hand, the notion of Yesod's widget is a very clever first step in the direction of web component abstraction.
So in conclusion, yes, Yesod went a step further from what I expected from server side web technologies when I discovered it.
I can't answer with certainty what the author means, but the next set of features planned for Yesod is to have tighter client-side integration. We also agree that's where web app development is headed, but we wanted to start with a solid server-side framework before branching into the client side.
> Note the awesome Shakespearean inspired name convention. Another good reason to use yesod.
Lol.
> Until here I believe it goes in the right direction. Even if I believe the real future is by generating HTML pages from the client (using javascript) and server limited to serve JSON (or XML, or any object representation system).
This is a little unclear. Do you mean, prior to Yesod you thought web development was heading in the right direction, but Yesod made you realize there was a much better way, even if the future is HTML5 rich web apps with the app server as a JSON/XML API endpoint?
1. http://yannesposito.com/Scratch/en/blog/Yesod-excellent-idea...