Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hoodie: very fast web app development

hood.ie

Post reply on HN
Print view View original

81–90 of 155 posts

Re: Hoodie: very fast web app development

#81

Post by d0m »

I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice?

Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything just stop working. I.e. links don't work anymore, button obviously don't.. Is there a better solution than a hard-refresh? Would a first-level try/catch solve this problem?

Thanks!

Re: Hoodie: very fast web app development

#82

Post by verbalist »

d0m wrote: post #81

I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice? Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything…

> non-js users

the web is no longer just text. if you need to consume text then you need a text-api client, which is what web browsers used to be.

Re: Hoodie: very fast web app development

#84

Post by d0m »

verbalist wrote: post #82
d0m wrote: post #81

I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice? Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything…

> non-js users the web is no longer just text. if you need to consume text then you need a text-api client, which is what web browsers used to be.

I know as tech people we're strong about using latest technologies and we like to think users are like us, but sadly, this is not the case. Actually, it really depends of your market.

"the web is no longer just text"

Although I can't deny that statement,I find it hard to convince myself that browsers can't read your page because no JS engines are running. I see it a little bit like emails.. yes, more recent clients give you a better interface or better features, but if I'm emailing someone who has a very old phone with very basic email support, I'm hoping that this person would still be able to read my message.

I'd love to see what would happen if HN turned JS-enabled only for a day.

Re: Hoodie: very fast web app development

#88

Post by eevee »

verbalist wrote: post #82
d0m wrote: post #81

I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice? Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything…

> non-js users the web is no longer just text. if you need to consume text then you need a text-api client, which is what web browsers used to be.

I run noscript. If I encounter a site that's broken or useless for seemingly no reason (e.g. not an interactive thing like Google Maps), I often don't even whitelist; I just leave. Relatedly, I've stopped clicking on Photobucket or Blogspot links.

I kinda resent being expected to run your pile of arbitrary code just to render static text and images on my screen—something that worked just fine without JS twenty years ago.

Re: Hoodie: very fast web app development

#89

Post by pjbrunet »

Lazare wrote: post #60
lifeisstillgood wrote: post #52

Earlier quoted context omitted.

hi I am trying very hard not to be dumb, but this is beating me seemingly Kanso? and Hoodie both have JS stubs at the client and server end, these synch with each other, then synch with whatever you are using at client (say backbone) and server (node? CouchDB? My Postgres server behind my python app?) If thats roughly right, why do I do this? I control my server apps no? Why wrap them in another layer? Json->backbone…

Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…

If my phone has no signal I'd rather see an error message. I don't want the app to pretend everything is fine when that's not the case. If I press "Delete" in the app, don't pretend the thing is deleted if it's not really deleted yet, that's deceptive. What if I take off on my boat and I press "Send" and your app says "Sent!" but it's really not sent because now I've left the coast--your app just lied to me.

Re: Hoodie: very fast web app development

#90

Post by jchrisa »

Lazare wrote: post #60
lifeisstillgood wrote: post #52

Earlier quoted context omitted.

hi I am trying very hard not to be dumb, but this is beating me seemingly Kanso? and Hoodie both have JS stubs at the client and server end, these synch with each other, then synch with whatever you are using at client (say backbone) and server (node? CouchDB? My Postgres server behind my python app?) If thats roughly right, why do I do this? I control my server apps no? Why wrap them in another layer? Json->backbone…

Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…

Great answer. Tiny nitpick: the next version of TouchDB is called Couchbase Lite. We call it that b/c it is made by Couchbase and is lighter than TouchDB.

Couchbase for Mobile is what we call the umbrella (including our Sync Gateway which adds multi-user access control with more scale and flexibility than CouchDB, but compatible with the same sync protocol).

Of course it's all open source with a very active community. Join us here: https://groups.google.com/forum/m/#!forum/mobile-couchbase

Post reply on HN