I am seeing more and more issues [1][2] around turbolinks and I'm wondering
if it's time to remove it from foreman. I have seen it recommended that
one shouldn't use the back button in foreman; I thought that request was
reserved for poorly written php sites that resubmit forms when the back
button is pressed, we're better than that! :)
Are the benefits of turbolinks worth the cost? Does anyone have any
metrics on the difference in page load times with and without
"turbo"links?
Any additional thoughts on its removal?
Cheers,
Walden
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1522740
[2] http://projects.theforeman.org/issues/21480
The idea behind turbolinks is good in general - it works great when
you have a standard Rails application with its view stack (ERB). When
I saw this talked, I liked it very much:
Unfortunately, we are not good fit. This works for a clean app which ERB and maybe little javascript. Foreman (and Katello) is a heavy JS app with various JS frameworks and perhaps it does not work well. At least this is my impression, I am very far from being a frontend developer :-)
LZ
--
Later,
Lukas @lzap Zapletal
Unfortunately, we are not good fit. This works for a clean app which ERB and maybe little javascript. Foreman (and Katello) is a heavy JS app with various JS frameworks and perhaps it does not work well. At least this is my impression, I am very far from being a frontend developer :-)
LZ
···
On Wed, Dec 6, 2017 at 4:10 PM, Walden Raines <wraines@redhat.com> wrote:I am seeing more and more issues [1][2] around turbolinks and I'm wondering
if it's time to remove it from foreman. I have seen it recommended that one
shouldn't use the back button in foreman; I thought that request was
reserved for poorly written php sites that resubmit forms when the back
button is pressed, we're better than that! :)
Are the benefits of turbolinks worth the cost? Does anyone have any metrics
on the difference in page load times with and without "turbo"links?
Any additional thoughts on its removal?
Cheers,
Walden
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1522740
[2] http://projects.theforeman.org/issues/21480
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Later,
Lukas @lzap Zapletal
I welcome the proposal to remove turbolinks, having said that, there are a
few things that we must take into account.
1. we should not just remove turbo links and loose all functionaitly - this will greatly impact current ui performance.
2. we should come up with an alternative plan - which is a roadmap to a SPA or semi SPA which will render the usage cases of tubolinks today not required.
IMHO - I would suggest we look into converting the vertical nav into a react component (some work already done at [1]), than using that as a base for a SPA, we should default to fetching content, either via api and using react to render it, or (which is the very common case) to let the server render html and replace a content div, this will mimic the current way turbolinks more or less works and will surely speed up the page load times.
We would need to move things like session / login / permissions etc into the browser if we go that path
Ohad
[1] https://github.com/patternfly/patternfly-react/pull/88
1. we should not just remove turbo links and loose all functionaitly - this will greatly impact current ui performance.
2. we should come up with an alternative plan - which is a roadmap to a SPA or semi SPA which will render the usage cases of tubolinks today not required.
IMHO - I would suggest we look into converting the vertical nav into a react component (some work already done at [1]), than using that as a base for a SPA, we should default to fetching content, either via api and using react to render it, or (which is the very common case) to let the server render html and replace a content div, this will mimic the current way turbolinks more or less works and will surely speed up the page load times.
We would need to move things like session / login / permissions etc into the browser if we go that path
Ohad
[1] https://github.com/patternfly/patternfly-react/pull/88
···
On Wed, Dec 6, 2017 at 5:10 PM, Walden Raines <wraines@redhat.com> wrote:I am seeing more and more issues [1][2] around turbolinks and I'm
wondering if it's time to remove it from foreman. I have seen it
recommended that one shouldn't use the back button in foreman; I thought
that request was reserved for poorly written php sites that resubmit forms
when the back button is pressed, we're better than that! :)
Are the benefits of turbolinks worth the cost? Does anyone have any
metrics on the difference in page load times with and without
"turbo"links?
Any additional thoughts on its removal?
I am seeing more and more issues [1][2] around turbolinks and I'm wonderingIf someone suggests the back button shouldn't be used within foreman because that breaks something - it's our fault. I recall some problems in some pages like Products/Errata etc.. but haven't seen any in a whlie
if it's time to remove it from foreman. I have seen it recommended that
one shouldn't use the back button in foreman; I thought that request was
reserved for poorly written php sites that resubmit forms when the back
button is pressed, we're better than that! :)
The request is used by Basecamp, GitHub, and modern Ruby applications, but honestly that's just an ad-hominem. (notice the blue bar when you click on a link in GitHub)
Do the test, it's considerably faster to use it, I'm happy to provide metrics. In fact for cached pages it can easily be 100ms (/subnets, /settings, etc)
Are the benefits of turbolinks worth the cost? Does anyone have any
metrics on the difference in page load times with and without
"turbo"links?
In fact, there's room to make it faster (data-turbolinks-permanent)
Unless there are serious blockers or anything that cannot be done with Turbolinks that we need to do, I really oppose this. If you have another alternative that's not pushState that makes Foreman faster and is as easy to use, I'd be glad to hear it
Any additional thoughts on its removal?
···
On 12/06, Walden Raines wrote:--
Cheers,
Walden
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1522740
[2] http://projects.theforeman.org/issues/21480
--
You received this message because you are subscribed to the Google Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Daniel Lobato Garcia
@dLobatog
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 Keybase: https://keybase.io/elobato
+1 to the comments above, moving forward with React will allow us to drop
turbolinks at some point without a noticeable decrease in UI performance -
at least that is my hope.
···
On Wed, Dec 6, 2017 at 5:46 PM, Ohad Levy <ohadlevy@gmail.com> wrote:
On Wed, Dec 6, 2017 at 5:10 PM, Walden Raines <wraines@redhat.com> wrote:
I am seeing more and more issues [1][2] around turbolinks and I'm
wondering if it's time to remove it from foreman. I have seen it
recommended that one shouldn't use the back button in foreman; I thought
that request was reserved for poorly written php sites that resubmit forms
when the back button is pressed, we're better than that! :)
Are the benefits of turbolinks worth the cost? Does anyone have any
metrics on the difference in page load times with and without
"turbo"links?
Any additional thoughts on its removal?
I welcome the proposal to remove turbolinks, having said that, there are
a few things that we must take into account.
1. we should not just remove turbo links and loose all functionaitly -
this will greatly impact current ui performance.
2. we should come up with an alternative plan - which is a roadmap to a
SPA or semi SPA which will render the usage cases of tubolinks today not
required.
IMHO - I would suggest we look into converting the vertical nav into a
react component (some work already done at [1]), than using that as a base
for a SPA, we should default to fetching content, either via api and using
react to render it, or (which is the very common case) to let the server
render html and replace a content div, this will mimic the current way
turbolinks more or less works and will surely speed up the page load times.
We would need to move things like session / login / permissions etc into
the browser if we go that path
Ohad
[1] https://github.com/patternfly/patternfly-react/pull/88
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Since https://github.com/theforeman/foreman/pull/5083 was merged most of my
issues with turbolinks have been fixed so I'm fine keeping it until we can
replace it with a true single page application.
···
On Thu, Dec 7, 2017 at 10:02 AM, Daniel Lobato Garcia <elobatocs@gmail.com> wrote:
On 12/06, Walden Raines wrote:
> I am seeing more and more issues [1][2] around turbolinks and I'm
wondering
> if it's time to remove it from foreman. I have seen it recommended that
> one shouldn't use the back button in foreman; I thought that request was
> reserved for poorly written php sites that resubmit forms when the back
> button is pressed, we're better than that!If someone suggests the back button shouldn't be used within foreman
because that breaks something - it's our fault. I recall some problems
in some pages like Products/Errata etc.. but haven't seen any in a whlieThe request is used by Basecamp, GitHub, and modern Ruby applications,
but honestly that's just an ad-hominem. (notice the blue bar when you click
on a link in GitHub)>
> Are the benefits of turbolinks worth the cost? Does anyone have any
> metrics on the difference in page load times with and without
> "turbo"links?Do the test, it's considerably faster to use it, I'm happy to provide
metrics.
In fact for cached pages it can easily be 100ms (/subnets, /settings, etc)https://www.speedshop.co/2015/05/27/100-ms-to-glass-with-
rails-and-turbolinks.htmlIn fact, there's room to make it faster (data-turbolinks-permanent)
>
> Any additional thoughts on its removal?Unless there are serious blockers or anything that cannot be done with
Turbolinks that we need to do, I really oppose this. If you have another
alternative that's not pushState that makes Foreman faster and is as easy
to
use, I'd be glad to hear it>
> Cheers,
> Walden
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1522740
> [2] Bug #21480: Disable turbolinks reloading on back button navigation - Katello - Foreman
>
> --
> You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.--
Daniel Lobato Garcia@dLobatog
blog.daniellobato.me
daniellobato.meGPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
