These are chat archives for jescalan/roots

11th
May 2016
oliver41
@oliver41
May 11 2016 13:12
how do you handle browersync in roots-mini?
Jeff Escalante
@jescalan
May 11 2016 13:48
we use the browsersync webpack plugin
it works great
reloads are extremely fast
initial compile will still be lengthy for large sites
Ben Styles
@benadamstyles
May 11 2016 14:00
@jenius if we're already using jade and webpack on a "classic roots" site, which is very large and takes over 15 mins to build, would you say that moving to roots-mini would bring a quicker build? From the blog post I got the idea that speed was one of your main aims with roots-mini, along with easier maintenance, but I don't know if I've got the wrong end of the stick? Does roots-mini bring better jade performance?
Jeff Escalante
@jescalan
May 11 2016 14:00
no
it brings much better reload performance
but the compilers we use are the compilers we use, we did not rewrite them
switching off of stylus will be a large speed boost
basically roots is extremely fast, but is throttled by the speed of the compilers
the only way to get a speed boost is to use faster compiled languages
generally stylus is by far the slowest one, jade and coffee are pretty quick
roots-mini tracks dependencies and in development only reloads changed files though, while roots does not do this because it supports a shitload of different compilers and not all of them return dependency trees
so in development you will have millsecond-speed reloads just about all the time
roots-mini is not stable at all though, and we release breaking changes regularly, so you should know this before thinking about a change
when it's slightly more stable we will release 0.1.0 and probably update the name to something nicer
when it's very stable we will push 1.0.0
Ben Styles
@benadamstyles
May 11 2016 14:04
Ok thanks very much, I thought that would be the case but I wanted to clarify. We're not using stylus. I'm pretty certain that the bottleneck is jade, but we are asking it to compile thousands of pages...!
Jeff Escalante
@jescalan
May 11 2016 14:04
and at some point soon we will move all roots properties into an organization, and roots itself will be put on LTS mode for a year or so
oh damn thousands of pages
Ben Styles
@benadamstyles
May 11 2016 14:05
I've achieved some speed improvements with micro-optimizations to the jade template that builds these pages
Jeff Escalante
@jescalan
May 11 2016 14:05
ah that is pretty good. i would love to read about this if you wrote an article or case study!
Ben Styles
@benadamstyles
May 11 2016 14:05
but I guess it's the single-thread that's the true bottleneck
Jeff Escalante
@jescalan
May 11 2016 14:05
yeah single thread hurts
and unfortunately that's a node-level block
Ben Styles
@benadamstyles
May 11 2016 14:06
yeah of course
Jeff Escalante
@jescalan
May 11 2016 14:06
i did in the past make a version of roots that was multi-threaded but did not work with any extensions, and did not allow any type of function to be passed as a local
and it was very fast, but the thread limitations hurt too much
Ben Styles
@benadamstyles
May 11 2016 14:07
Don't suppose you have that code still around anywhere?
Jeff Escalante
@jescalan
May 11 2016 14:07
hmm i might, let me take a look
Ben Styles
@benadamstyles
May 11 2016 14:07
Thanks v much. Might give me an idea on a new extension to fire up some threads
or something
Ah brilliant, cheers
Jeff Escalante
@jescalan
May 11 2016 14:08
threads are called "processes" in node, and only strings can be passed between them
they work fine, but the string limitation is tough to deal with
Ben Styles
@benadamstyles
May 11 2016 14:09
Yep. It might just be enough in our use case. Incidentally, I don't suppose the W.all in roots-records compile step could be counterintuitively slower than synchronously compiling file-by-file?
A bit of a straw-clutch...
Jeff Escalante
@jescalan
May 11 2016 14:09
dont see how that would be possible
Ben Styles
@benadamstyles
May 11 2016 14:10
No ok :)
Jeff Escalante
@jescalan
May 11 2016 14:10
the issue with roots' compiles is that it's forced into sync mode by thread-blocking from compilers
so while the core is entirely async, when you run a cpu-intensive operation on the main thread, it blocks
whereas things like fs.readFile actually just implement a process behind the scenes
since you only need strings for that type of transaction it works
what would really boost speed is if people wrote node compilers that were threaded-async
Ben Styles
@benadamstyles
May 11 2016 14:13
yep. Ok this is all really helpful. Thanks so much
Jeff Escalante
@jescalan
May 11 2016 14:13
:+1:
Ben Styles
@benadamstyles
May 11 2016 14:14
The long build actually is not so bad except it's hitting th netlify 15 minute limit. We can pay to extend it though so that will probably be the solution. I will take a look at your multi-process commit and see if I have any ideas. Cheers.
Jeff Escalante
@jescalan
May 11 2016 14:28
hah damn, 15 minutes
thats crazy
is there any potential more js-based solution?
Ben Styles
@benadamstyles
May 11 2016 14:31
I have been thinking about using a different compiler for this one template
Something faster than jade, if such a thing exists
it's really hard to get any idea of benchmarks for different template langs though
What we're doing is grabbing user data using roots-records then compiling fairly simple user profile pages using a single Jade template.
I thought it would be slow but I wasn't expecting over 10 minutes to be honest.
Jeff Escalante
@jescalan
May 11 2016 14:34
i think ejs would be faster
and its supported out of the box
bc jade has to parse whitespace, ejs does not
Ben Styles
@benadamstyles
May 11 2016 14:35
Ah yeah of course!
Brilliant, ok I will try it
Thanks! I will report back. By the way, when I said about micro-optimizations, the biggest speed boost was passing in lazy.js as a jade local function and using that to loop through stuff instead of standard js array methods.
Also caching some big arrays between files, rather than creating them anew in each file, by saving them to a jade local from within the jade template
Jeff Escalante
@jescalan
May 11 2016 14:43
ah nice, i havent used lazy.js but i was checking it out the other day
good to hear it works well
Ben Styles
@benadamstyles
May 11 2016 14:43
I swear by it!
Jeff Escalante
@jescalan
May 11 2016 14:43
:grin:
Jeff Escalante
@jescalan
May 11 2016 16:00
good news guys we finally have documentation for what compilers you can use
truly i am embarassed it took this long to release, especially since making this page took me a grand total of about 5 minutes
Tom Kraak
@tkraak
May 11 2016 16:03
yay!
oliver41
@oliver41
May 11 2016 17:24
Can anybody tell me what is the best way to make a multilanguage site with roots (not templating languages but en and fr for example)

Is it a good idea just to work with data-lang attributes?
'<!-- Example multilingual -->

<script>
$(function(){
//set or get lang
$('body').attr('data-current-lang','en');

$('[data-switch-lang]').click(function(){

  var newLang = $(this).attr('data-switch-lang'),
      currentLang = $('body').attr('data-current-lang');

  if (newLang !== currentLang){

    //swap content
    $('[data-lang="' + newLang + '"]').show();
    $('[data-lang="' + $('body').attr('data-current-lang') + '"]').hide();

    //set language for future needs
    $('body').attr('data-current-lang',newLang);

    //optional
    $('.dropdownTrigger[data-dropdown-id="language"]').text(newLang);
  }

});

});

</script>'

Ben Styles
@benadamstyles
May 11 2016 17:43
You can try my roots extension, with all the caveats I mention in the README: https://www.npmjs.com/package/roots-i18n
Ben Styles
@benadamstyles
May 11 2016 20:01
@jenius – 3 MINUTES!!
Jeff Escalante
@jescalan
May 11 2016 20:02
?
Ben Styles
@benadamstyles
May 11 2016 20:03
Build time: ~15 minutes -> ~3 minutes
Your ejs tip appears to have done the business by a massive margin
I can't believe it!
Jeff Escalante
@jescalan
May 11 2016 20:26
daaamn
nice work
:+1:
thats a big deal
little things times thousands equals big things
Jeff Escalante
@jescalan
May 11 2016 20:39
hey everyone, we are doing some big moving and renaming soon
all roots properties are going to move to an organization called static-dev
this org will also host spike, formerly known as roots-mini, which is our next generation roots-like project
just a heads up!