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

Stimulus: A modest JavaScript framework for the HTML you already have

github.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#81

Post by JoshMnem »

sheraz wrote: post #25

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/turbo…

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

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#82

Post by nailer »

scarface74 wrote: post #77
nailer wrote: post #74

Earlier quoted context omitted.

Yep, I'd fire the CTO.

Not if the CTO said he chose Lotus Notes and Tivoli because they were in Gartner's magic quadrant based on the long gone consultants he hired. Yes, I know it's a circular argument, but that's how corporate America works.

The mediocre kind sure. But they'd get sacked at a tech company easily.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#83

Post by c8d3f7b49897918 »

andrei_says_ wrote: post #80
c8d3f7b49897918 wrote: post #48

Earlier quoted context omitted.

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/05/08/hatoeas-is-for-humans.ht...

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?

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

And you can simply open the the unit test page in question:

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#84

Post by cyberferret »

triskweline wrote: post #45
sheraz wrote: post #25

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/turbo…

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

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?

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#85

Post by jaredcwhite »

crescentfresh wrote: post #69
jaredcwhite wrote: post #32

As a Rails dev, I find this very interesting. I've already jumped on the Vue bandwagon and have had a pretty good time using it. That being said, I recently started a new small-ish Rails project and loaded Vue in via 5.1's Webpack integration...and ended up just hacking together some jQuery stuff for minor front-end dynamism. It just was easier/faster for me to do that in this particular context. However, I could def…

> Vue is overkill The number of projects where something as small and simple as Vue could be considered overkill has to be remarkably small, I feel. I've used Vue in single pages (i.e. a single page of a large application) inside a single div as needed. In my case attaching behavior inside a modal dialog (ie the modal was managed by some other framework). It is very small and lean as is.

I should have worded that better...in this context, it's not that Vue the library is overkill, but the overall paradigm. Vue's not well-suited to server-rendered HTML that has some dynamic features after the fact.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#86

Post by jakecopp »

JoshMnem wrote: post #81
sheraz wrote: post #25

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/turbo…

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…

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#87

Post by bmh_ca »

jdc0589 wrote: post #70
sheraz wrote: post #25

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/turbo…

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…

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.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#88

Post by jacobsenscott »

jakecopp wrote: post #86
JoshMnem wrote: post #81

Earlier quoted context omitted.

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…

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

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#89

Post by flaviojuvenal »

JoshMnem wrote: post #81
sheraz wrote: post #25

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/turbo…

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…

I guess that Turbolinks is used by Basecamp 2 and it sucks a lot. Search takes seconds to load for me, without any loading feedback.

Re: Stimulus: A modest JavaScript framework for the HTML you already have

#90

Post by JoshMnem »

jacobsenscott wrote: post #88
jakecopp wrote: post #86

Earlier quoted context omitted.

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

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.
Post reply on HN