Hey everybody! These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid.
Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn’t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed. Cheers Richard > On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira <pedro.duquevie...@gmail.com> > wrote: > > In the blog post he makes it sounds like it isn't good for anything to have > that. That it is just a bug, something that wasn't well thought through and > reviewed or a pointless feature. Which I totally disagree with. I think it > can be very interesting to take advantage of that. > > I think the performance problem he measured was more about the buffering > issue than about dynamically reloading the stylesheet whenever there's a > change. But yeah, this might have a performance impact. If there is indeed > a considerable impact, perhaps we could have a flag to opt out of this > feature. That way we can have the best of both worlds and not have this > feature impact the apps performance in production. > > Cheers, > > > A good feature during development is not necessarily a good feature during >> production, especially if it (apparently) has a significant performance >> impact. >> But I see your point. >> >> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>> Hi >>> >>> I actually totally disagree with his conclusion. >>> >>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>> Check out CSSFX and this video >> https://www.youtube.com/watch?v=RELKg32xEWU >>> to understand the advantages of this feature (ScenicView has also >>> integrated CSSFX to take advantage of this). >>> >>> Think about the productivity boost of tweaking your UI at runtime and not >>> having to go through the cycle: tweak UI -> compile -> run -> (No that's >>> not it) -> close app -> tweak UI again -> compile again -> run again -> >> (No >>> that's not it again) -> [repeat till infinity] >>> >>> Also think about the potential for adding tools that build on top of this >>> feature. Tools like firebug or features from Chrome developer tools, etc, >>> that they use on the web to debug / tweak UIs during runtime. >>> >>> Cheers, >>> >>> >>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>> Hi all, >>>>> >>>>> I just came across this blog post which complains about a badly >>>> implemented stream reader in JavaFX. The general tone is not nice, but I >>>> figured this could be useful to the developers maintaining this area: >>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>>>> >>>>> Best regards, >>>>> >>>>> Clement >>>>> PS: I landed on this blog post because I was searching for some >> pointers >>>> on a coding problem I have with JavaFX Service / Task, which might or >> might >>>> not involve inputStreams. I share it here: >>>> >> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>>>> -- >>>>> Cl?ment Levallois >>>>> Associate Professor >>>>> emlyon business school >>>>> Twitter and Skype: @seinecle >>>>> mobile: +33(0)6 59 08 33 92 >>>>> >>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>> > > > -- > Pedro Duque Vieira - https://www.pixelduke.com
