5 ms·

Responsive JavaScript in Rails: load what you need when you need it

21 points by pothibo 13y ago

RyanZAG 13y ago
GWT actually does this automatically, works very nicely: http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.h...
- pothibo 13y ago
  That is very cool, I'm reading it right now, thanks for the link
asnyder 13y ago
NOLOH (http://www.noloh.com http://www.noloh.com) has been doing this automatically since 2006. Disclaimer: I was one of the co-founders.
dschiptsov 13y ago
The much simpler idea is to stop using bloated, general purpose frameworks, and just use tiny, functional-style hooks when needed, the way people used JS in days before the framework madness.)
- pkorzeniewski 13y ago
  After using several frameworks in various projects, I must agree with that. The main problem with frameworks is that they work well until you try to do something they weren't designed for - and then you end up with a pile of hacky and messy code. With smaller libraries it's much easier to replace one for another or just write your own small piece of code that will do exactly what you want.
- rfnslyr 13y ago
  Could you please go more in depth about "functional-style hooks ... before the framework madness"? I'd be interested in reading your thoughts as a newbie JS dev currently studying backbone/angular/jquery and other libraries.
  - pothibo 13y ago
    I believe that what he meant (Correct me if I'm wrong), is that instead of creating a system of classes that tries to abstract everything out of the DOM, it's better act on the DOM itself, via jQuery, Zepto.js, etc. In some ways, what I showed in the post is functional. - Select a DOM i.e var $elem = $("#anElementId") - Act on it i.e $elem.fadeOut()
    - platz 13y ago
      And yet what about the "JQuery soup" problem that everyone complains about? Isn't that due to having DOM manipulation code strewn about willy-nilly?
      - pothibo 13y ago
        Sometimes, it's good to encapsulate stuff into a class when you have a complex logic around a specific theme. It's not one or the other. It's one AND the other.
  - dschiptsov 13y ago
    There was a nice set of slides few days ago - http://www.slideshare.net/nzakas/enough-withthejavascriptalready http://www.slideshare.net/nzakas/enough-withthejavascriptalr... - exactly the same idea.
bryanlarsen 13y ago
Of course, the drawback of this approach is that you're now sending javascript with every request. If you had done the traditional approach of sending your javascript in one big minified chunk it only needs to be sent once and your browser will load it from cache on subsequent requests.
- pothibo 13y ago
  You are right, and I quickly went over it because I was scared of loosing the focus of the post by explaining into details many small parts. This is a balance you have to consider. If a user never clicks on the link, this method has an advantage over minifying everything since you would load the JS without using it. On the other hand, if a user keeps clicking the link while being on the same page (Important to stay on the same page), it would be better to have it stored in your minified chunk. It's a low hanging fruit optimization that can be very useful IMO.
at-fates-hands 13y ago
This is actually a step up from what I've been doing which is using views to selectively load what JS a certain page actually needs - instead of bloating it up with several different libraries or frameworks that are all gang banging the page when it loads. Performance wise, I've seen a significant increase in page load times.
bchhun 13y ago
Here's pothibo's talk code samples that he mentions in the beginning of the post: https://github.com/pothibo/open-code-ajax https://github.com/pothibo/open-code-ajax I liked the idea and added a demo using Flask/Python as well :)
- pothibo 13y ago
  Thanks for sharing! The talk is in french so you guys might want to skip the talk and jump to the code ;)
blktiger 13y ago
I've always wondered if it wouldn't be interesting to treat certain parts of a web application kind of like Objective-C NIB files. NIBs are sort of used to load new code into the application at run-time. We could do something similar with javascript maybe? Load parts of the UI in chunks based on what the user is currently doing with the application so that initial load times are lower.
- pothibo 13y ago
  Yes I believe this could very well exist and I'd be happy using something like this. I thought about using WebSockets to send HTML/JS stuff down the pipe as the user navigates. Would cut some lagging due to how HTTP request are made and would decrease the load time.

21 points by pothibo 13y ago

GWT actually does this automatically, works very nicely: http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.h...

pothibo 13y ago
That is very cool, I'm reading it right now, thanks for the link

asnyder 13y ago

NOLOH (http://www.noloh.com http://www.noloh.com) has been doing this automatically since 2006. Disclaimer: I was one of the co-founders.

dschiptsov 13y ago

The much simpler idea is to stop using bloated, general purpose frameworks, and just use tiny, functional-style hooks when needed, the way people used JS in days before the framework madness.)

pkorzeniewski 13y ago
After using several frameworks in various projects, I must agree with that. The main problem with frameworks is that they work well until you try to do something they weren't designed for - and then you end up with a pile of hacky and messy code. With smaller libraries it's much easier to replace one for another or just write your own small piece of code that will do exactly what you want.
rfnslyr 13y ago
Could you please go more in depth about "functional-style hooks ... before the framework madness"? I'd be interested in reading your thoughts as a newbie JS dev currently studying backbone/angular/jquery and other libraries.
- pothibo 13y ago
  I believe that what he meant (Correct me if I'm wrong), is that instead of creating a system of classes that tries to abstract everything out of the DOM, it's better act on the DOM itself, via jQuery, Zepto.js, etc. In some ways, what I showed in the post is functional. - Select a DOM i.e var $elem = $("#anElementId") - Act on it i.e $elem.fadeOut()
  - platz 13y ago
    And yet what about the "JQuery soup" problem that everyone complains about? Isn't that due to having DOM manipulation code strewn about willy-nilly?
    - pothibo 13y ago
      Sometimes, it's good to encapsulate stuff into a class when you have a complex logic around a specific theme. It's not one or the other. It's one AND the other.
- dschiptsov 13y ago
  There was a nice set of slides few days ago - http://www.slideshare.net/nzakas/enough-withthejavascriptalready http://www.slideshare.net/nzakas/enough-withthejavascriptalr... - exactly the same idea.

bryanlarsen 13y ago

Of course, the drawback of this approach is that you're now sending javascript with every request. If you had done the traditional approach of sending your javascript in one big minified chunk it only needs to be sent once and your browser will load it from cache on subsequent requests.

pothibo 13y ago
You are right, and I quickly went over it because I was scared of loosing the focus of the post by explaining into details many small parts. This is a balance you have to consider. If a user never clicks on the link, this method has an advantage over minifying everything since you would load the JS without using it. On the other hand, if a user keeps clicking the link while being on the same page (Important to stay on the same page), it would be better to have it stored in your minified chunk. It's a low hanging fruit optimization that can be very useful IMO.

at-fates-hands 13y ago

This is actually a step up from what I've been doing which is using views to selectively load what JS a certain page actually needs - instead of bloating it up with several different libraries or frameworks that are all gang banging the page when it loads. Performance wise, I've seen a significant increase in page load times.

bchhun 13y ago

Here's pothibo's talk code samples that he mentions in the beginning of the post: https://github.com/pothibo/open-code-ajax https://github.com/pothibo/open-code-ajax I liked the idea and added a demo using Flask/Python as well :)

pothibo 13y ago
Thanks for sharing! The talk is in french so you guys might want to skip the talk and jump to the code ;)

blktiger 13y ago

I've always wondered if it wouldn't be interesting to treat certain parts of a web application kind of like Objective-C NIB files. NIBs are sort of used to load new code into the application at run-time. We could do something similar with javascript maybe? Load parts of the UI in chunks based on what the user is currently doing with the application so that initial load times are lower.

pothibo 13y ago
Yes I believe this could very well exist and I'd be happy using something like this. I thought about using WebSockets to send HTML/JS stuff down the pipe as the user navigates. Would cut some lagging due to how HTTP request are made and would decrease the load time.