Server-side HTML vs. JS Widgets vs. Single-Page Web Apps(blog.pamelafox.org)
blog.pamelafox.org
Server-side HTML vs. JS Widgets vs. Single-Page Web Apps
http://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.html
9 comments
I've had the most mileage out of single-page web apps. So much of your code is perfectly untrustable UI logic that can live on the client anyway. I use http://meteor.com so I never run into issues with latency or spotty ORMs...
I am a huge fan of JS-heavy single page apps paired with a nice REST Api to exchange JSON data. That's how we've built the dashboard at userfox.com and I've seen this same architecture pop up at other shops since. What makes this especially appealing to me was the fact that I was pretty much developing the API along with the web app. An API that can also be used by other clients in the future (native smart phone apps, etc.)
I love the benefits on single-page web apps, but the SEO issues associated with them and the current methods to get around it (using selenium to do a render of the html on the server?!?) keeps me from using them on things.
It seems to me that by using node.js on the server, we should be able to share the application code, including rendering to html/dom. I have a vision in my mind of an http request coming in to the server for a given url, ember.js picking it up and rendering views/templates into html that is sent over the server. On a javascript client, that html/dom would need to be linked into ember.js on the client-side (this could be done be either regenerating the html, or by "deserializing it" in some way). Further actions on the page could be handled by the client-side javascript in normal ember.js fashion.
This approach would have several benefits. Initial response would have working html that could be rendered without having to wait on loading the application's javascript (along with dependencies) and would be workable for non-javascript clients, such as web crawlers and older clients. Links in this html could default to be links back to the server for other full page requests, and only switch to using ember.js on the client if and when the javascript loads. Applications would have even more reason to make their interactions with the page routable via url and therefore easily linkable and sharable.
Normally when developing websites, you shy away from too much in the javascript because of these usability/SEO concerns and the normal approaches involve writing the same logic on the client and on the server (normally not even in the same language). With javascript on the server, why don't we run the same code on both ends, remove this handicap, and use the benefits to offload processing to the clients when possible but still provide a server-based fallback for the many cases when it is necessary?
It seems to me that by using node.js on the server, we should be able to share the application code, including rendering to html/dom. I have a vision in my mind of an http request coming in to the server for a given url, ember.js picking it up and rendering views/templates into html that is sent over the server. On a javascript client, that html/dom would need to be linked into ember.js on the client-side (this could be done be either regenerating the html, or by "deserializing it" in some way). Further actions on the page could be handled by the client-side javascript in normal ember.js fashion.
This approach would have several benefits. Initial response would have working html that could be rendered without having to wait on loading the application's javascript (along with dependencies) and would be workable for non-javascript clients, such as web crawlers and older clients. Links in this html could default to be links back to the server for other full page requests, and only switch to using ember.js on the client if and when the javascript loads. Applications would have even more reason to make their interactions with the page routable via url and therefore easily linkable and sharable.
Normally when developing websites, you shy away from too much in the javascript because of these usability/SEO concerns and the normal approaches involve writing the same logic on the client and on the server (normally not even in the same language). With javascript on the server, why don't we run the same code on both ends, remove this handicap, and use the benefits to offload processing to the clients when possible but still provide a server-based fallback for the many cases when it is necessary?
I'm not very familiar with Node, but I had assumed that a more flexible or movable client/server dividing line was the point of Node, and assumed it's what people were already doing... but maybe not. Can any Node afficianados speak to this question?
I am not an afficianado by any means, but it does help in some ways. Many libraries exist that can run on both sides of the connection. Unfortunately, I haven't found much that allow you to modify the DOM/html using the same code on client and server, and even less that allows you to go from an application state on the server into an identical state on the client. Meteor.js, Opa, and Derby.js seem to be the main options in this field, but I'd like to see a simple javascript library that facilitates this so that many other frameworks can take advantage of it.
AFAIK this is solved in Derby.js; it serves fully-rendered HTML to the client and JS kicks in after that.
I haven't come across this before. I will have to play with it and see how it works. It definitely appears to be in alpha status, but then again, so are most javascript frameworks, it seems :)
There is a lot I kind of dislike about single-page web apps and I don't think they provide enough benefit to outweigh the inherent complexity of them.
My current favorite combination is server side rendering + knockout. Minimal JS to get the job done and has a mental model that I enjoy. Also, less futzing with yet another template engine like mustache.
My current favorite combination is server side rendering + knockout. Minimal JS to get the job done and has a mental model that I enjoy. Also, less futzing with yet another template engine like mustache.
Very nice discussion and slides, the videos added a lot.
My favorite approach is somewhat in the middle. You might call it an "MSPA" - Multiple Single Page Apps, each major section in the app is it's own standalone SPA. (public searchable pages are plain HTML e.g. using Jekyll).
For example, if I have an admin section with master detail scenario, this would consist of a single SPA, And an "account" section with settings + and profile sections will be also it's own SPA. I only keep it "SPA" where it makes sense to keep the same context, and where there are frequent transitions between section's pages.
p.s. I like your stack (Backbone, Django, Play). my specific stack of choice is not that far though I eventually moved from backbone to AngularJS and never looked back. With Scala I use it just as Servlets / JAX-RS on steroids instead of Play, I found performance to be better.
My favorite approach is somewhat in the middle. You might call it an "MSPA" - Multiple Single Page Apps, each major section in the app is it's own standalone SPA. (public searchable pages are plain HTML e.g. using Jekyll).
For example, if I have an admin section with master detail scenario, this would consist of a single SPA, And an "account" section with settings + and profile sections will be also it's own SPA. I only keep it "SPA" where it makes sense to keep the same context, and where there are frequent transitions between section's pages.
p.s. I like your stack (Backbone, Django, Play). my specific stack of choice is not that far though I eventually moved from backbone to AngularJS and never looked back. With Scala I use it just as Servlets / JAX-RS on steroids instead of Play, I found performance to be better.
(Post author) Good point, we actually do take that approach - we have about 8 different Backbone apps currently, for different aspects of the admin and student experience. We don't have a hard and fast rule for when we break into a new app, but it usually becomes obvious at some point. And it's not too hard to refactor that sort of thing, since it's mostly just changing a routes file around.
i like this approach a lot too. it takes a fair amount of discipline to do properly though.
ideally you want to be able to, on some level, iterate on different apps at different rates, and also share apps between various different stacks.
ideally you want to be able to, on some level, iterate on different apps at different rates, and also share apps between various different stacks.
I'm interested in single-page application frameworks... however as a developer whose built UI's for desktop applications I find the focus on the MVC design pattern rather strange. I've tried learning how to build these kinds of interfaces in Backbone and friends. However the learning curve is rather high and the metaphors don't make a lot of sense. I was surprised when, after bugging my JS developer friends, I finally got "Hello, world!" up on the screen.
As a test I was able to get a native cocoa application up on the screen in <30 lines of CL.
I realize it must have something to do with the whole document/DOM relationship that has perversed UI programming on the web this way... but it also doesn't seem like there's a way out. It's just not elegant so lets stop using that word.
As a test I was able to get a native cocoa application up on the screen in <30 lines of CL.
I realize it must have something to do with the whole document/DOM relationship that has perversed UI programming on the web this way... but it also doesn't seem like there's a way out. It's just not elegant so lets stop using that word.
You're right that the complexity derives from the DOM. But in my opinion the DOM isn't so much the problem as the fact that it is so hard to manipulate. There are two ways to manipulate it: by low-level node fiddling at a level far below that of the discrete UI elements being represented, or by deleting subtrees and replacing them from a serialized source (html), losing event handlers and embedded state in the process. Neither solution is usable when dealing with complex ui elements that have no corresponding html tag, so you end up needing an abstraction layer that implements of these mechanisms and does the boilerplate work to make it practical. Because of this abstraction layer things always get complicated as soon as you try to move beyond basic html tags with onclick handlers beause you end up learning the pseudo-dsl of the abstraction layer.
The long term solution is to make html itself extensible so you can define additional tags at the start of the page, with all the related logic, and then can go back to straight dom manipulation without needing any abstraction framework. This should become possible with web components and shadow dom, but we have a way to go still.
The long term solution is to make html itself extensible so you can define additional tags at the start of the page, with all the related logic, and then can go back to straight dom manipulation without needing any abstraction framework. This should become possible with web components and shadow dom, but we have a way to go still.
In our framework, we basically have "pages" which can be loaded/unloaded using AJAX for you, and "tools" which you can put on pages. So a developer can quickly put together an app out of pages and tools, and wire it up, with just a bit of data going between the server and the client. What's more, he or she can set up heavy caching (e.g. on a CDN) of the AJAX responses, making the entire interface render client-side like a native app. We even have support for storing a bundle locally -- in, say, PhoneGap -- and still use the newest files as they are updated on the server in subsequent releases.
Components and models are loaded "on demand", and instead of MVC -to- MVC syncing we have opted to have one MVC, with the authoritative model on the server, and messages being broadcast to all participants in the stream.
So basically the "best practice" is to grab some existing tools and stream types, or create new ones. Everything "just works" out of the box.
Components and models are loaded "on demand", and instead of MVC -to- MVC syncing we have opted to have one MVC, with the authoritative model on the server, and messages being broadcast to all participants in the stream.
So basically the "best practice" is to grab some existing tools and stream types, or create new ones. Everything "just works" out of the box.
Is the framework available/visible anywhere? It's a neat approach, one I've thought about but never done anything towards. Kudos for turning it into reality!
Yep, you can see some of it here;
http://qbix.com/blog http://framework.qbix.com
we are working on rolling out a much better framework portal for it though.
http://qbix.com/blog http://framework.qbix.com
we are working on rolling out a much better framework portal for it though.
I can't see too much on the second link. What's the point if it is password protected and you don't give it away?
We are building it in a cathedral before releasing 0.9 to the bazaar :)
Pardon my shameless plug, but I've been working on something for a looong time that combines all of the above into one massive time-saving system. The hardest part is definitely making it fast and efficient while also being user friendly.
If you take a look at the trends of the web over the past decade, I really think this (or something like it) is the future of web application development. Long story short, you can (mostly) point-and-click to build flexible/reusable JS widgets that can either be laid out on a single page or embedded elsewhere. (Side note: I developed a system on top of jQuery similar to backbone that should eventually allow the widgets' HTML to be cached and loaded instantly, as opposed to regenerating each widget's components from its JSON representation every time. This is where "Server-side HTML vs. JS Widgets vs. Single-Page Web Apps" all come together.)
I've already posted a description in a comment before, so I apologize if you've happened to have already read it. Here's a more detailed description:
It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned).
Before I link to it, I'd like to apologize for overly generic descriptions currently on the site. I whipped together the entire site in a few days not knowing the exact direction I wanted to take the software, so I left everything pretty vague; I really just wanted some content that at least somewhat described my ideas. I'll put the link at the bottom of this comment so you read all this first. From a technical standpoint, this is currently where I'm at with it:
- Users create a myriad of widgets that can "interact" with each other; the fullscreen version of Loggur consists of "layouts" of widgets, while the mobile version of Loggur lets you access widgets individually in typical mobile app fashion
- Databases are incredibly easy to create; just add fields to a widget and specify their relationships to one another
- All kinds of special extensions included by default, like automatic importing of various data sources, scraping of websites, cron jobs, PDF report generation, emails, sms notifications, triggers, and graphing
- Everything is taggable for reuse, from the apps themselves to widgets to components to elements to lists and to the data associated with all of the above; you can either "mirror" or "clone" any one of these parts in another app/widget/component by doing a quick search for tags (or if you know the exact path to the part, just enter that); so for example, if you really liked what someone else has made and wanted to reuse parts of it in your own app, you'd do a quick search for it, clone it, and modify it to suit your needs, saving a lot of time
- Data associated with apps can be any combination of public/private, singular (your individual profile), and/or group-specific; you can quickly/immediately switch between views of each
- Permissions on everything; specify who can view and/or edit apps, widgets, components, elements, lists, and/or data
- Appearances are somewhat customizeable and will become much more so at some point; customization currently consists of the basics like colors, backgrounds, and sizes; apps are designed to be scalable to any screen resolution (think large dashboards ;)
- Each one of the pieces outlined above (widgets, components, etc.) can be embedded on your own site(s) through small snippets of code
- Data associated with apps is easily accessible, currently only available in JSON but if for some reason other formats are requested in high numbers, I might do that
- Users can toggle the ability to view app/data updates as they happen in realtime; they can also invite each other (or a Loggur dev if they need help) to take turns using/building an app
- Regarding the mention above about rewriting the project to be more modular/flexible for developers, I felt doing this was 100% necessary/worth it because it occurred to me a few months ago that the best approach to make this succeed in the long term is to make this a legitimate platform (buzzword, sorry!) where developers can quickly/easily make and share awesome extensions and be rewarded (paid) for their work
Check it out (sign up for it ;) here and remember to ignore the bad, vague descriptions currently on the site: http://loggur.com
If you take a look at the trends of the web over the past decade, I really think this (or something like it) is the future of web application development. Long story short, you can (mostly) point-and-click to build flexible/reusable JS widgets that can either be laid out on a single page or embedded elsewhere. (Side note: I developed a system on top of jQuery similar to backbone that should eventually allow the widgets' HTML to be cached and loaded instantly, as opposed to regenerating each widget's components from its JSON representation every time. This is where "Server-side HTML vs. JS Widgets vs. Single-Page Web Apps" all come together.)
I've already posted a description in a comment before, so I apologize if you've happened to have already read it. Here's a more detailed description:
It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned).
Before I link to it, I'd like to apologize for overly generic descriptions currently on the site. I whipped together the entire site in a few days not knowing the exact direction I wanted to take the software, so I left everything pretty vague; I really just wanted some content that at least somewhat described my ideas. I'll put the link at the bottom of this comment so you read all this first. From a technical standpoint, this is currently where I'm at with it:
- Users create a myriad of widgets that can "interact" with each other; the fullscreen version of Loggur consists of "layouts" of widgets, while the mobile version of Loggur lets you access widgets individually in typical mobile app fashion
- Databases are incredibly easy to create; just add fields to a widget and specify their relationships to one another
- All kinds of special extensions included by default, like automatic importing of various data sources, scraping of websites, cron jobs, PDF report generation, emails, sms notifications, triggers, and graphing
- Everything is taggable for reuse, from the apps themselves to widgets to components to elements to lists and to the data associated with all of the above; you can either "mirror" or "clone" any one of these parts in another app/widget/component by doing a quick search for tags (or if you know the exact path to the part, just enter that); so for example, if you really liked what someone else has made and wanted to reuse parts of it in your own app, you'd do a quick search for it, clone it, and modify it to suit your needs, saving a lot of time
- Data associated with apps can be any combination of public/private, singular (your individual profile), and/or group-specific; you can quickly/immediately switch between views of each
- Permissions on everything; specify who can view and/or edit apps, widgets, components, elements, lists, and/or data
- Appearances are somewhat customizeable and will become much more so at some point; customization currently consists of the basics like colors, backgrounds, and sizes; apps are designed to be scalable to any screen resolution (think large dashboards ;)
- Each one of the pieces outlined above (widgets, components, etc.) can be embedded on your own site(s) through small snippets of code
- Data associated with apps is easily accessible, currently only available in JSON but if for some reason other formats are requested in high numbers, I might do that
- Users can toggle the ability to view app/data updates as they happen in realtime; they can also invite each other (or a Loggur dev if they need help) to take turns using/building an app
- Regarding the mention above about rewriting the project to be more modular/flexible for developers, I felt doing this was 100% necessary/worth it because it occurred to me a few months ago that the best approach to make this succeed in the long term is to make this a legitimate platform (buzzword, sorry!) where developers can quickly/easily make and share awesome extensions and be rewarded (paid) for their work
Check it out (sign up for it ;) here and remember to ignore the bad, vague descriptions currently on the site: http://loggur.com
"I would have released it months ago but decided to rewrite nearly everything"
Recipy for disaster. Release early, release often.
Is this b.t.w. a one-man project? Big code bases written by one man which doesn't get out to the public early is a risky undertaking.
However I really admire your passion/enthousiasm.
Recipy for disaster. Release early, release often.
Is this b.t.w. a one-man project? Big code bases written by one man which doesn't get out to the public early is a risky undertaking.
However I really admire your passion/enthousiasm.
Yeah it's just me for now. There would be too much overhead involved in getting anyone else up to speed on it and getting them on the same wavelength. I have a fair amount of documentation, so when I everything is finished that I personally have to do, bringing in others won't be an issue then as it would be now.
I beg to differ about your claim that delaying its release by a few months is a recipe for disaster. If you saw what I had written prior to the rewrite... that was a recipe for disaster. First impressions are huge. And this project isn't your typical easy come, easy go type of startup. There's a lot to it, and if one piece of the puzzle is missing, it stands no chance in the real world, so it has to be done right from the very beginning. I do have a list of things that would be okay to do after its initial release, of course.
I have plenty of runway time, so the reality of it is that releasing it months ago instead of months from now would not have been beneficial at all. If anything, I'd have gotten discouraged because of complaints of massive amounts of bugs and complaints about lack of features/functionality, and I'd have ended up rushing to write code and it would be ugly. But since I have plenty of runway to spare, I can do it right and release everything (mostly) as advertised, save a few gray hairs, and maybe even have better timing on its release. Timing is everything. And if you asked me a year ago, I would have said the world is not yet ready for Loggur.
I'm noticing a trend on HN that quite a few people seem to think there's one path to take for a successful startup. Repeating the "release early, release often" mantra is evidence of this fact. Yes, that mindset might work for the majority of startups, but certainly not all of them.
I beg to differ about your claim that delaying its release by a few months is a recipe for disaster. If you saw what I had written prior to the rewrite... that was a recipe for disaster. First impressions are huge. And this project isn't your typical easy come, easy go type of startup. There's a lot to it, and if one piece of the puzzle is missing, it stands no chance in the real world, so it has to be done right from the very beginning. I do have a list of things that would be okay to do after its initial release, of course.
I have plenty of runway time, so the reality of it is that releasing it months ago instead of months from now would not have been beneficial at all. If anything, I'd have gotten discouraged because of complaints of massive amounts of bugs and complaints about lack of features/functionality, and I'd have ended up rushing to write code and it would be ugly. But since I have plenty of runway to spare, I can do it right and release everything (mostly) as advertised, save a few gray hairs, and maybe even have better timing on its release. Timing is everything. And if you asked me a year ago, I would have said the world is not yet ready for Loggur.
I'm noticing a trend on HN that quite a few people seem to think there's one path to take for a successful startup. Repeating the "release early, release often" mantra is evidence of this fact. Yes, that mindset might work for the majority of startups, but certainly not all of them.
Waiting until it's done can make first-impressions better, and iron out potential bad-decisions that might then have to be supported. ReRo can become a mantra sometimes.
It is pretty disappointing that these comparisons always seem to consider the server side template case as "we did it in the most horrible way possible, I know all the issues we had were solved long ago and we could do it right, but lets pretend that isn't possible because I want an excuse to do everything in javascript".
Yeah. To me, the pros and cons ought to assume you're Doing It Right; otherwise, you're probably better off learning to Do It Right than changing your approach.
I see the tradeoffs as:
Server-side rendering gives you better language choices, but it's more expensive to the site owner than serving static HTML/CSS/JS for pages and using AJAX for data only. Client-side rendering is often more performant for the end user than server-side, but that depends on the device and the application.
Which one makes sense, then, depends on whether client-side rendering is actually faster for your application and expected user device usage patterns, and how much you value better language choices versus lower server costs.
As with absolutely everything else in software, there's no one-size-fits-all correct answer.
I see the tradeoffs as:
Server-side rendering gives you better language choices, but it's more expensive to the site owner than serving static HTML/CSS/JS for pages and using AJAX for data only. Client-side rendering is often more performant for the end user than server-side, but that depends on the device and the application.
Which one makes sense, then, depends on whether client-side rendering is actually faster for your application and expected user device usage patterns, and how much you value better language choices versus lower server costs.
As with absolutely everything else in software, there's no one-size-fits-all correct answer.
(Post author) Yep, I know that our server-side case was the worst possible way. It is possible to do it in infinitely better ways, but it's still hard to do so in a way that easily brings in JavaScript and doesn't end up replicating code, especially when your server-side language and front-end language are different. I got a demo of DerbyJS the author day, a framework on top of Node that does server-side rendering of the template so it loads very fast, and then subscribes to events via JS and refreshes the template on the client-side, all using the same template code and language. That to me sounds like a pretty cool approach, but not something we can switch to easily.