ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arzhan Kinzhalin <>
Subject Re: A question about require (ripple): why build-time stacking instead of runtime injection?
Date Tue, 09 Jun 2015 20:23:34 GMT
Some additional thoughts on this... After some distractions at the office,
I'm back to the work I've started doing on the UI/App split and I'm finding
that runtime loading/rendering would be even more valuable to make the

Currently, both scripts and html are processed at build time to make a
usable versions of these. So, to make them behave differently in runtime
(e.g. load and initialize properly), entire parallel build logic for a
split configuration is needed in addition to changes to the runtime JS
code. It would be much easier if the code would govern loading the scripts
and resources and the configuration (monolith or split) in runtime instead:

1. Load dependencies via requirejs (
2. Load resources (overlays, dialogs etc.) via requirejs/text.
3. Render html templates server-side via some template mechanism (e.g.
4. Use client-side template rendering for dialogs, overlays, error
notifications and so on.

It is a kind of big change, though, so I will most likely end up creating a
parallel "split" build logic for the first iteration, but ideally, it
should be all done at runtime, IMO. Doing all that at build-time creates
another, completely detached, logic that has to be maintained (in form of
Jake code/repository naming conventions) while there's no good reason (I
guess) to not do it all at runtime in development environment.

Just some thoughts out loud...

On Fri, Jun 5, 2015 at 4:12 PM, Arzhan Kinzhalin <> wrote:

> I find it difficult to have a debugging session on a file that have >55K
> lines of code. Debuggers let you search by functions, independently of file
> context.
> There’s a reason programmers put stuff in different files. :) And I’d like
> to keep this 1-to-1 mapping for development environment and be able to
> reload the browser to see the changes (w/o detour via the command line).
> So, if there’s no particular technical reason, I think introducing a dev
> environment which reads the files on the file system without intermediate
> build steps has on objections, really. Those who prefer BLOBs, will have it
> as well.
> --
> // kai
> On Jun 5, 2015, at 15:50, Horn, Julian C <> wrote:
> I also don’t find it difficult to debug Ripple in its release/combined
> form, as long as it isn't minified. It can sometimes be convenient to be
> able to search around when everything is all in one file.  When you find
> the site you want to change you can always find out what individual file
> you are in by searching backwards for the nearest define.  When I shift
> from problem analysis to implementing a fix I kind of change gears anyway.
> Also, when I debug a problem from the field I always debug using the
> release form so the stack tracebacks match up.
>    Julian
> -----Original Message-----
> From: Tim Barham [
> <>]
> Sent: Friday, June 05, 2015 2:17 PM
> To:
> Subject: RE: A question about require (ripple): why build-time stacking
> instead of runtime injection?
> Don't know of any technical requirement, though interestingly with script
> injection in Cordova ... are you referring plugin scripts? Because they're
> moving towards a model where they're concatenated at build time (using
> browserify) rather than injected at runtime.
> For me with Ripple, I just make sure I'm at least always working against a
> non-uglified version of the source :).
> -----Original Message-----
> From: Arzhan Kinzhalin [ <>]
> On Behalf Of Arzhan Kinzhalin
> Sent: Friday, June 5, 2015 11:06 AM
> To:
> Subject: A question about require (ripple): why build-time stacking
> instead of runtime injection?
> Hi all;
> I was wondering if there’s a reason for require() (which is aliased to
> ripple) to have its current form? I understand it’s been taken as-is from
> cordova, but even cordova does inject script instead of stacking them up
> into a huge poorly debuggable blob.
> I guess my question is whether there was a specific technical reason to
> use cordova-require/build-time pack combination instead of
> cordova-require/runtime inject or plain require.js? Is it purely historical
> or is there some technical background that I am missing?
> Major disadvantage is that the development environment is unnecessarily
> complicated. We could have two versions: running ripple for dev environment
> and release version (optimised/concatenated). Would this be a reasonable
> change? If the dev community around this project is to grow, the
> development environment should be friendly. :)
> --
> // kai

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message