by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 15 2016 15:37
    EECOLOR commented #43
  • Oct 17 2016 20:20
    divmain labeled #78
  • Oct 15 2016 23:05

    divmain on master

    Nit: Tweak template comment. (compare)

  • Oct 09 2016 12:27
    mightyiam opened #78
  • Oct 08 2016 08:07

    divmain on master

    Update compilation-pluggables J… (compare)

  • Oct 08 2016 07:55

    divmain on master

    remove old files Switch CI to use Node v6.3.0. (compare)

  • Oct 08 2016 07:28

    divmain on master

    Split code generation out into … 0.10.7 (compare)

  • Sep 26 2016 07:19

    divmain on master

    Include preceding `/` in JS bun… 0.10.6 (compare)

  • Sep 18 2016 08:59
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:58
    divmain edited #12
  • Sep 18 2016 08:57
    divmain edited #12
  • Sep 18 2016 08:57
    divmain edited #12
Dale Bustad
@divmain
I don't disagree with you though
huge fan!
FRP is the gold standard in web app development, in my mind
Shahar Dawn Or
@mightyiam
I bet a builder would be awesome as a cycle app
Drivers as good candidates for build "targets" (targets?)
Dale Bustad
@divmain
hmm that's an interesting thought
isn't Cycle.js a frontend SPA framework?
Shahar Dawn Or
@mightyiam
Agnostic
Dale Bustad
@divmain
really? i didn't realize that
that's interesting
Shahar Dawn Or
@mightyiam
The cycle principle is very simple. You don't have to use the DOM driver at all
Dale Bustad
@divmain
yeah, that's true
Shahar Dawn Or
@mightyiam
While it may change, I've some free time now (read not employed). Do you reckon you'd consider looking at this with me?
Dale Bustad
@divmain
building on top of cycle.js?
Shahar Dawn Or
@mightyiam
Yeah
Dale Bustad
@divmain
have to be honest: my time for open source is pretty limited, and I also maintain another large-ish project (GitSavvy)
I barely have time to move things forward with Interlock as-is
Shahar Dawn Or
@mightyiam
I consider it a fabulous contribution to the web community and a badge on my career shoulder
Dale Bustad
@divmain
so I probably don't have time to spend on exploring a rewrite
I might be able to answer questions as you go - in fact, I'd be happy to do that if I can
so if you want input on the AST ecosystem or various bundling strategies, please do ask
Shahar Dawn Or
@mightyiam
I'll look into the code. See if I can understand what's the general data flow
Dale Bustad
@divmain
that sounds good
it's a visualization of the compilation process from start to finish, and each smaller intermediate steps
all of it is documented and all of it links to the original code if you want to read that too
Shahar Dawn Or
@mightyiam
Comes the time, I'd be happy to give an introduction talk about this in the Israel JavaScript meetup
Dale Bustad
@divmain
that'd be great @mightyiam
Shahar Dawn Or
@mightyiam
@divmain may I have you for a short interrogation, please?
I can use a good explanation of the various objects. I probably require a bit of various explanations. Best to do it live, it seems to me.
Dale Bustad
@divmain
@mightyiam that's a good idea
this is also the next piece of documentation that I'm working on
all the datastructure and objects that are flowing through the compilation
Shahar Dawn Or
@mightyiam
Any progress, @divmain ?
Dale Bustad
@divmain
hey @mightyiam
I've been getting GitSavvy (another OSS project) squared away with new collaborators
hopefully that'll free up more of my time to work on Interlock
I put some time into documenting the build architecture
hopefully this can answer a number of the questions you may have about how things work, what the various objects are, what properties they have, and why
if you find that there is missing information, please let me know (ideally in the form of an issue in the www.interlockjs.com repo)
posting your thoughts here works too
there may be more information than you need
the docs are intended to be consumable by anyone with an intermediate understanding of JS
so it starts slow and lays the ground-work, not assuming too much pre-existing knowledge
the runtime architecture docs are in the queue, although I may be making some changes there
to the actual behavior
I also need to do the obvious docs of getting started, how to use the CLI, these are the compilation options available, etc
EECOLOR
@EECOLOR

Is there an example available for an isomorphic build? In this type of build one would have two entries (client.js and server.js).client.js and it's dependencies are resolved (browser field in package.json) and prepared for the browser (different babel settings). server.js and it's dependencies (which overlap for a large part with client.js) are resolved and prepared for node.

If I would refer to an image, it can just use the same image, it should not processed twice. For both client and server it can use the same parsed AST for the overlapping parts (the App).

It would be really amazing if interlock would the go-to buildtool for isomorphic applications, current build tools make this situation very tricky to achieve.

My question was: is this possible and is an example available?