Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#1

Post by richmok » Mon, Jun 03, 2013, 5:23 AM UTC

Server-side HTML vs. JS Widgets vs. Single-Page Web Apps
blog.pamelafox.org

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#2

Post by zinssmeister » Mon, Jun 03, 2013, 6:09 AM UTC

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

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#3

Post by tfb » Mon, Jun 03, 2013, 7:02 AM UTC

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

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#4

Post by EGreg » Mon, Jun 03, 2013, 7:31 AM UTC

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.

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#5

Post by porker » Mon, Jun 03, 2013, 8:16 AM UTC

EGreg wrote: post #4

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 l…

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!

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#6

Post by doctorpangloss » Mon, Jun 03, 2013, 8:22 AM UTC

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

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#7

Post by agentultra » Mon, Jun 03, 2013, 11:28 AM UTC

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

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#8

Post by nubs » Mon, Jun 03, 2013, 2:03 PM UTC

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?

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#9

Post by programminggeek » Mon, Jun 03, 2013, 2:07 PM UTC

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.

Re: Server-side HTML vs. JS Widgets vs. Single-Page Web Apps

#10

Post by TeeWEE » Mon, Jun 03, 2013, 2:10 PM UTC

tfb wrote: post #3

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…

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