Server-side HTML vs. JS Widgets vs. Single-Page Web Apps • Hacker News Board

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

#21

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

sixbrx wrote: post #17

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

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.

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

#22

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

wmf wrote: post #14

nubs wrote: 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.

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

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

#23

Post by pamelafox » Mon, Jun 03, 2013, 6:07 PM UTC

eranation wrote: post #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 setti…

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

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

#24

Post by pamelafox » Mon, Jun 03, 2013, 6:10 PM UTC

papsosouid wrote: post #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".

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

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

#25

Post by EGreg » Mon, Jun 03, 2013, 10:47 PM UTC

lobo_tuerto wrote: post #19

EGreg wrote: post #11

Earlier quoted context omitted.

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?

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

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

#26

Post by Chris2048 » Mon, Jun 03, 2013, 11:31 PM UTC

TeeWEE wrote: post #10

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.

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.