Live data from Hacker News

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

blog.pamelafox.org

11–20 of 26 posts

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

#11
post #5
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!

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.

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

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

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

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

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

#14
post #8

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…

AFAIK this is solved in Derby.js; it serves fully-rendered HTML to the client and JS kicks in after that.

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

#15

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

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.

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

#16

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.

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

#17
post #8

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…

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?

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

#18
post #10
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.

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.

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

#19
post #11
post #5

Earlier quoted context omitted.

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.

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?

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

#20

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

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.

Post reply on HN