Hacker News Reader

Comment by carsongross | Hacker News Reader

Main intercooler.js author here, glad to answer any questions.

Happy to see people are enjoying it!

I'm a huge fan of intercooler.js because most of web dev today is going to monumental lengths to hide the progress bar overtop of what used to be simple client/server RPCs (in other words, the vast majority of it is a waste of all of our time).

I really feel that the web is moving towards a components/modularized system where every tag is built from subtags, a bit like how iframes used to work but without the security implications. For example, I was shocked when I learned back in the 90s that server-side includes where generally disabled on servers, which led to the proliferation of cgi-bin, php, ruby, node.js, etc etc which may not have been necessary otherwise.

To get to my question - is adding websocket/socket.io on the horizon? If intercooler.js can get to a truly push-based method of state synchronization, it would be huge.

Yeah, a core idea of intercooler is to take the original web architecture seriously and not try to shoe-horn 90's style client/server architecture into the web:

http://intercoolerjs.org/docs.html#philosophy

I'm looking to add server-side event support in the next month or so, which would give us a nice way to implement push-based updates:

https://github.com/LeadDyno/intercooler-js/issues/131

I'm working on a demo chat UI myself, so I will be motivated to add it soon. :)

With the addition of server push this would be an ideal tool for a web game I've been vaguely working on --- I keep getting lost in a maze of client/server code. With intercooler it may just all go away.

(I was unaware of EventSource. It looks so, so much nicer to use than raw WebSockets...)

As an aside: Intercooler obviously requires Javascript to work; is there any fallback if Javascript's not available? It sounds like, at least for interactions on things like form buttons, it ought to be possible to send an old fashioned POST to the server which rerenders the entire page.

Cool I hadn't heard about server-sent events. They look straightforward enough, my main concern is that the separator between messages is two newlines. It would have been better if they used an arbitrary boundary string like in multipart/form-data to be symmetric with traditional form data, so that a pseudorandom string/md5/sha could be used to separate binary data segments (especially when the contents and their length were not known in advance):

http://stackoverflow.com/questions/3508338/what-is-the-bound...

Now unfortunately there will be a requirement client-side to decode binary data or strings with escaped newlines. We'll get the benefit of deterministic behavior at the cost of escaping payloads, and I'm not certain it's worth it.

This seems like an opportunity lost to me. Big enough that this may be one of the basic building blocks we skipped over in the rush to javascript. Maybe the community could wrap this to look like a client-side form until there is a standard.

The browser EventSource API handles decoding, so there shouldn't be a need for browser client code to worry about it if that's the concern.

As a non fronted developer playing arond with web technologies I was impressed by IC.js. It is really easy to get it work (is like boring HTML) and it works pretty well with web2py. Using it does not feel like "engineering something" but some people simply want to drive a car without getting their hands dirty.

Is there a typical pattern for progressive enhancement, going from the non-js case to the intercooler case when js is enabled?

Not yet, beyond the somewhat ugly duplicating of anchor tag hrefs and form actions and then checking for the 'ic-request' variable on requestsion.

It's on the list.

How do you see this comparing with older existing solutions like Rails' Unobtrusive JavaScript? It has always handled this kind of thing very well for me, and has been around a long time.

https://github.com/rails/jquery-ujs

I think it builds on a lot of those older ideas, but is a bit more explicit and tuned towards what modern web apps have evolved into. Pjax and Turbolinks were direct inspirations.

This is sort of a meta thing, but I'm curious how many hits/stars you got on the github page from hn

I started today w/ 1400 stars

Why did you choose to use a custom attribute rather than a `data-` one?

I like how custom attributes look better, when I saw how Angular was using them.

You can use the data-prefix though if you want by including the following meta tag:

  <meta name="intercoolerjs:use-data-prefix" content="true"/>

I know it's largely hypothetical, but by not using data-, aren't you running the risk of namespace collisions in future? data- attributes are guaranteed not to ever have an 'official' version that the browser expects, while anything else may exist in the future.

any chance of a jquery-free option?

Yes, it's on the list. I expect some time in 2017.

Reply on news.ycombinator.com