7 ms·

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been p

by sheraz 9y ago

I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing. These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc. [1] - https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks [2] - http://intercoolerjs.org/ http://intercoolerjs.org/

triskweline 9y ago
If you enjoy working with intercooler.js but are looking for a bit more power, check out Unpoly [1]. [1]: https://unpoly.com https://unpoly.com
- cyberferret 9y ago
  Thanks for the heads up. I've worked with Intercooler before and while it is a really nice framework, I've always felt it was missing a few critical things. Unpoly looks cool. Do you know if it has a dependency on jQuery still, like Intercooler does? Or does it run independently?
  - triskweline 9y ago
    Unpoly currently depends on jQuery. Work is being done to remove that dependency eventually, but that will take time.
  - NoGravitas 9y ago
    Small correction: intercooler works with either jQuery or zepto.
  - edwinyzh 9y ago
    Hello, I've been watching intercoolerjs also, and thinking of using it in a future project. What are the few critical things missing have you experienced ?
c8d3f7b49897918 9y ago
Thank you for the kind words about intercooler.js. :) If you are interested in some reading on the theory behind it, I recommend these two blog posts that explain how HTML and REST/HATEOAS hang together better than Javascript with JSON: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
- andrei_says_ 9y ago
  I am really liking intercoolerjs and noticing that Stimulus will not work with IE11 which I need to support. What is the browser support for intercoolerjs?
  - c8d3f7b49897918 9y ago
    intercooler should work in any browser that your chosen version of jquery or zepto works in. If you want to see if a particular browser is compatible with a particular version of intercooler + (jquery || zepto), the unit tests are linked off the release page: http://intercoolerjs.org/download.html http://intercoolerjs.org/download.html And you can simply open the the unit test page in question: http://intercoolerjs.org/release/unit-tests-1.2.1.html?hidepassed http://intercoolerjs.org/release/unit-tests-1.2.1.html?hidep... This will run all tests for intercooler 1.2.1 using jQuery3 as the underlying library. Be sure to let the window retain focus or a few tests will fail.
  - javan 9y ago
    > noticing that Stimulus will not work with IE11 which I need to support See: https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#browser-support https://github.com/stimulusjs/stimulus/blob/master/INSTALLIN...
    - andrei_says_ 9y ago
      Thank you
aaron-lebo 9y ago
Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolation are complex. Mithril is actually smaller than Intercooler and is everything included, so there's no need to put together a stack if you don't feel like it. The stack you are offering is great, and it's great in the right situation, but I just wanted to push back against the "complexity" argument because it happens a lot and it makes me afraid that it is pushing devs into more familiar but less capable stacks. Your React/Vue stack might be a little more setup, but it's also going to scale. The Turbolinks/Intercooler approaches seem to be managing state with the DOM, and as someone who has spent the last six months pulling the state out of the DOM from a jQuery app, it does not scale. But anyone who has used both approaches in a moderately sized app can tell you this, it's why stuff like React exist at all.
- bphogan 9y ago
  Front-end stuff doesn't have to be complex, but it is. For example, a lot of places using React think they need Redux too. And React-router. And many other components. React itself is quite simple. But the architectures that developers build are often incredibly complex. This was the case with jQuery, Angular, and things that came before. I see two main problems in software development, especially on the front-end. First, developers jump on brand-new ground-breaking frameworks and use them in production, learning how they work as they go. This results in brittle systems. That's not necessarily bad, but it's not always great from a maintenance perspective. React is hot right now. But there are a ton of in-production Angular 1.x apps out there because that was what was hot when those projects started. That brings me to the second problem in tech - developers doing the "hot new thing" displaying a ton of hubris. It's "easy" and "straightforward", implying that anyone who doesn't get it just isn't smart or will be obsolete soon. I'd worry more about losing my job due to not keeping up with machine learning rather than not learning whatever new JS framework people think is hot right now. Here's the deal - web developers figured out server-side rendering 20 years ago, and managed to make turning databases into web pages easy about 12 years ago. It's possible to create applications that people love using a lot of that technology, with some JS on top. It's certainly faster to go to market with something that way. Not every app is Facebook. A lot of the stuff people work on outside of HN fall into one of two categories: 1. Apps that are behind a firewall - internal in nature, used by a handful of enterprise users. 2. Apps that won't be around in 3 years from now because the company will shift focus/replace it with an off-the-shelf product/company gets acquired. In both those cases, I'd look for the simplest approach to get something running, and simplest to maintain. Bottom line: it's easier to leverage existing skill-sets than it is to ask people to learn a whole new thing all the time. Anyway, at the end of the day, I don't really get too worked up about how another person chooses to solve the "make the browser display a web app." Every situation is different. React can be simple. So can server-side rendering with some Knockout/Stimulus/Intercooler/jQuery sprinkled around. Maintainable quality code that makes money wins in the long run. Whatever you implement it in.
jdc0589 9y ago
its not "cool" anymore, but I always thought knockout was pretty simple, worked well, and fulfilled a lot of this use-case. I built a couple knockout based apps that worked phenomenally well across lots of platforms, and were pretty lightweight dependency wise. Organization and convention was paramount to keep consistent since it doesn't enforce a bunch of best practices like a larger framework would; but, looks like all of these sit in basically that same space.
- bloomca 9y ago
  I double that knockout is amazing (and never targeted "true" frontend space, like routing), but from my point of view, it is targeted towards more "rich" applications. So while it is possible to use it the same way as Turbolinks (or React), it is kind of between, which makes it is harder to justify. However, it works perfect. So, if you read this, and you have it in your project, don't rush to replace with shiny new stuff.
  - jdc0589 9y ago
    > and never targeted "true" frontend space, like routing that was why it didn't catch on as much as it could have, in my opinion. The thing is, it was SO easy to rig routing together quickly yourself; I ended up doing dom event based routing for a lot of stuff. If you actually took the time to throw a real/reusable hash or pushstate based router on it would be pretty damn good....
- bmh_ca 9y ago
  I'm one of the knockout core developers. Just a heads up, knockout 3.5 just went into beta, and 4.0 is in alpha. I spoke the other day with another core developer, Ryan Niemeyer, and he noted that ko is still a good fit for quick and lightweight dynamics, but with good conventions a solid foundation for really complex Web apps. It's still very solid, and the API largely unchanged since IE6 was around. Tko, the monorepo for ko 4+, will hopefully make it easier to build frameworks out of the knockout code, so things like routers can be easier to tack on (if we don't build one in). Incidentally I've just set up a patreon for tko/ko 4 in particular at patreon.com/brianmhunt- it'd be great to be able to have more time to hack at it.
JoshMnem 9y ago
Turbolinks are not good for usability. They appear to make the pages painfully slow on slower connections. They add a loading bar across the top which can have different meanings depending on the site and browser: - some browsers add a bar across the top to indicate page loading progress (example: Firefox for Android) - some websites add a bar across the top to indicate how far you've read in an article - turbolinks adds yet another bar across the top to also indicate page loading progress I'm sure that using turbolinks is fine for people with fast Internet connections and certain types of websites/browsers, but it's terrible for usability in some scenarios. (`rails new app --skip-turbolinks`)
- jakecopp 9y ago
  I haven't tried out Turbolinks yet, however wouldn't the developer implementing Turbolinks make sure they don't have a progress bar along the top for another purpose first? I think users would understand it is a loading bar and not a reading progress bar if it only appears after a link is clicked. Also, if Turbolinks is implemented will Firefox on Android still display a second progress bar? I ask these questions as I'm thinking of using Turbolinks myself and your comment does make me doubt.
  - jacobsenscott 9y ago
    I've used turbolinks in production and it is great. The progress bar is clunky, but it is optional, and not needed anyway if your pages render in a reasonable amount of time (100ms to 200ms is "instant" to most people). I can't really fathom how the parent to your post saw a slowdown using turbolinks - because the server doesn't know the difference, and the client does less work.
    - JoshMnem 9y ago
      Turbolinks is often a terrible user experience. The user doesn't measure page load in seconds, but in the perceived load in seconds. Turbolinks on slow connections feels painful, including on big sites with fast servers, like YouTube and Github.
crescentfresh 9y ago
Wonderful prior discussion on intercoolerjs, albeit a bit old: https://news.ycombinator.com/item?id=12885980 https://news.ycombinator.com/item?id=12885980

by sheraz 9y ago

triskweline 9y ago

If you enjoy working with intercooler.js but are looking for a bit more power, check out Unpoly [1]. [1]: https://unpoly.com https://unpoly.com

cyberferret 9y ago
Thanks for the heads up. I've worked with Intercooler before and while it is a really nice framework, I've always felt it was missing a few critical things. Unpoly looks cool. Do you know if it has a dependency on jQuery still, like Intercooler does? Or does it run independently?
- triskweline 9y ago
  Unpoly currently depends on jQuery. Work is being done to remove that dependency eventually, but that will take time.
- NoGravitas 9y ago
  Small correction: intercooler works with either jQuery or zepto.
- edwinyzh 9y ago
  Hello, I've been watching intercoolerjs also, and thinking of using it in a future project. What are the few critical things missing have you experienced ?

c8d3f7b49897918 9y ago

Thank you for the kind words about intercooler.js. :) If you are interested in some reading on the theory behind it, I recommend these two blog posts that explain how HTML and REST/HATEOAS hang together better than Javascript with JSON: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

andrei_says_ 9y ago
I am really liking intercoolerjs and noticing that Stimulus will not work with IE11 which I need to support. What is the browser support for intercoolerjs?
- c8d3f7b49897918 9y ago
  intercooler should work in any browser that your chosen version of jquery or zepto works in. If you want to see if a particular browser is compatible with a particular version of intercooler + (jquery || zepto), the unit tests are linked off the release page: http://intercoolerjs.org/download.html http://intercoolerjs.org/download.html And you can simply open the the unit test page in question: http://intercoolerjs.org/release/unit-tests-1.2.1.html?hidepassed http://intercoolerjs.org/release/unit-tests-1.2.1.html?hidep... This will run all tests for intercooler 1.2.1 using jQuery3 as the underlying library. Be sure to let the window retain focus or a few tests will fail.
- javan 9y ago
  > noticing that Stimulus will not work with IE11 which I need to support See: https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#browser-support https://github.com/stimulusjs/stimulus/blob/master/INSTALLIN...
  - andrei_says_ 9y ago
    Thank you

aaron-lebo 9y ago

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolation are complex. Mithril is actually smaller than Intercooler and is everything included, so there's no need to put together a stack if you don't feel like it. The stack you are offering is great, and it's great in the right situation, but I just wanted to push back against the "complexity" argument because it happens a lot and it makes me afraid that it is pushing devs into more familiar but less capable stacks. Your React/Vue stack might be a little more setup, but it's also going to scale. The Turbolinks/Intercooler approaches seem to be managing state with the DOM, and as someone who has spent the last six months pulling the state out of the DOM from a jQuery app, it does not scale. But anyone who has used both approaches in a moderately sized app can tell you this, it's why stuff like React exist at all.

bphogan 9y ago
Front-end stuff doesn't have to be complex, but it is. For example, a lot of places using React think they need Redux too. And React-router. And many other components. React itself is quite simple. But the architectures that developers build are often incredibly complex. This was the case with jQuery, Angular, and things that came before. I see two main problems in software development, especially on the front-end. First, developers jump on brand-new ground-breaking frameworks and use them in production, learning how they work as they go. This results in brittle systems. That's not necessarily bad, but it's not always great from a maintenance perspective. React is hot right now. But there are a ton of in-production Angular 1.x apps out there because that was what was hot when those projects started. That brings me to the second problem in tech - developers doing the "hot new thing" displaying a ton of hubris. It's "easy" and "straightforward", implying that anyone who doesn't get it just isn't smart or will be obsolete soon. I'd worry more about losing my job due to not keeping up with machine learning rather than not learning whatever new JS framework people think is hot right now. Here's the deal - web developers figured out server-side rendering 20 years ago, and managed to make turning databases into web pages easy about 12 years ago. It's possible to create applications that people love using a lot of that technology, with some JS on top. It's certainly faster to go to market with something that way. Not every app is Facebook. A lot of the stuff people work on outside of HN fall into one of two categories: 1. Apps that are behind a firewall - internal in nature, used by a handful of enterprise users. 2. Apps that won't be around in 3 years from now because the company will shift focus/replace it with an off-the-shelf product/company gets acquired. In both those cases, I'd look for the simplest approach to get something running, and simplest to maintain. Bottom line: it's easier to leverage existing skill-sets than it is to ask people to learn a whole new thing all the time. Anyway, at the end of the day, I don't really get too worked up about how another person chooses to solve the "make the browser display a web app." Every situation is different. React can be simple. So can server-side rendering with some Knockout/Stimulus/Intercooler/jQuery sprinkled around. Maintainable quality code that makes money wins in the long run. Whatever you implement it in.

jdc0589 9y ago

its not "cool" anymore, but I always thought knockout was pretty simple, worked well, and fulfilled a lot of this use-case. I built a couple knockout based apps that worked phenomenally well across lots of platforms, and were pretty lightweight dependency wise. Organization and convention was paramount to keep consistent since it doesn't enforce a bunch of best practices like a larger framework would; but, looks like all of these sit in basically that same space.

bloomca 9y ago
I double that knockout is amazing (and never targeted "true" frontend space, like routing), but from my point of view, it is targeted towards more "rich" applications. So while it is possible to use it the same way as Turbolinks (or React), it is kind of between, which makes it is harder to justify. However, it works perfect. So, if you read this, and you have it in your project, don't rush to replace with shiny new stuff.
- jdc0589 9y ago
  > and never targeted "true" frontend space, like routing that was why it didn't catch on as much as it could have, in my opinion. The thing is, it was SO easy to rig routing together quickly yourself; I ended up doing dom event based routing for a lot of stuff. If you actually took the time to throw a real/reusable hash or pushstate based router on it would be pretty damn good....
bmh_ca 9y ago
I'm one of the knockout core developers. Just a heads up, knockout 3.5 just went into beta, and 4.0 is in alpha. I spoke the other day with another core developer, Ryan Niemeyer, and he noted that ko is still a good fit for quick and lightweight dynamics, but with good conventions a solid foundation for really complex Web apps. It's still very solid, and the API largely unchanged since IE6 was around. Tko, the monorepo for ko 4+, will hopefully make it easier to build frameworks out of the knockout code, so things like routers can be easier to tack on (if we don't build one in). Incidentally I've just set up a patreon for tko/ko 4 in particular at patreon.com/brianmhunt- it'd be great to be able to have more time to hack at it.

JoshMnem 9y ago

Turbolinks are not good for usability. They appear to make the pages painfully slow on slower connections. They add a loading bar across the top which can have different meanings depending on the site and browser: - some browsers add a bar across the top to indicate page loading progress (example: Firefox for Android) - some websites add a bar across the top to indicate how far you've read in an article - turbolinks adds yet another bar across the top to also indicate page loading progress I'm sure that using turbolinks is fine for people with fast Internet connections and certain types of websites/browsers, but it's terrible for usability in some scenarios. (`rails new app --skip-turbolinks`)

jakecopp 9y ago
I haven't tried out Turbolinks yet, however wouldn't the developer implementing Turbolinks make sure they don't have a progress bar along the top for another purpose first? I think users would understand it is a loading bar and not a reading progress bar if it only appears after a link is clicked. Also, if Turbolinks is implemented will Firefox on Android still display a second progress bar? I ask these questions as I'm thinking of using Turbolinks myself and your comment does make me doubt.
- jacobsenscott 9y ago
  I've used turbolinks in production and it is great. The progress bar is clunky, but it is optional, and not needed anyway if your pages render in a reasonable amount of time (100ms to 200ms is "instant" to most people). I can't really fathom how the parent to your post saw a slowdown using turbolinks - because the server doesn't know the difference, and the client does less work.
  - JoshMnem 9y ago
    Turbolinks is often a terrible user experience. The user doesn't measure page load in seconds, but in the perceived load in seconds. Turbolinks on slow connections feels painful, including on big sites with fast servers, like YouTube and Github.

crescentfresh 9y ago

Wonderful prior discussion on intercoolerjs, albeit a bit old: https://news.ycombinator.com/item?id=12885980 https://news.ycombinator.com/item?id=12885980