
Server-side HTML vs. JS Widgets vs. Single-Page Web Apps - richmok
http://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.html
======
doctorpangloss
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...

------
zinssmeister
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.)

------
nubs
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?

~~~
sixbrx
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?

~~~
nubs
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.

------
programminggeek
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.

------
eranation
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.

~~~
pamelafox
(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.

------
agentultra
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.

~~~
Joeri
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.

------
EGreg
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.

~~~
porker
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!

~~~
EGreg
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.

~~~
lobo_tuerto
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?

~~~
EGreg
We are building it in a cathedral before releasing 0.9 to the bazaar :)

------
tfb
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>

~~~
TeeWEE
"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.

~~~
tfb
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.

------
papsosouid
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".

~~~
rtfeldman
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.

