A bit overwhelmed these days

[Bruno Jouhier]

Hello streamline community,

I haven't been calling for help so far but I'm involved into too many things these days and it is becoming difficult for me to handle all the issues in a timely manner. My top priority is transformation and runtime bugs. I'll try to fix those ASAP (fortunately they don't come too often) but I may take time to respond to the other bugs/suggestions. So if you have something that annoys you and that you want to get fixed quickly, don't hesitate to submit a PR.

I'll still try to keep the issue list small but I'll give priority to the hard ones (like #181 futures on non-streamline calls).

Regarding the code, I'm pretty happy with the organization of the transformation and runtime code. It could of course be reviewed and improved but it's often tricky. So I'd rather take a conservative approach here: if it ain't broke don't fix it!

On the other hand, I'm not as happy with the rest (compile, compileSync, register, underscore). There has been quite a bit of back and forth on these modules and the code has become a bit messy. Also it could be simplified, for example by keeping only the sync version of the compile layer (the async is useless behind require, and not that useful for command line either - people who embed the transform usually just need the transform API). But here, I'm hesitating to restructure because there are lots of usage scenarios and it is difficult to guarantee that everything will continue to work, and I just don't have the time to do it, QA it, etc. But, if someone volunteers to restructure this, I'll welcome the effort (provided the result is clean and does not break too many things - should be done in an unstable branch first). But no real urgency here either. It works well enough as is, at least for us.

Don't take this as a sign of desinvestment. We (Sage) have a very strong investment in streamline; we'll keep investing in it and I'll keep supporting it. But it is difficult for me to support all usage scenarios, especially as we don't have any real urgent needs for new features for our own project. What we have today works great for us.

Also I want to thank all the contributors. The recent addition of sourcemaps support is a killer feature! And kudos again to Seth for the great blog article and video.

Bruno

[Seth Pollack]

Bruno, i've always been impressed with how responsive you've been on issues. But i'm glad you are asking for help -- the more people that are more deeply involved, the better for the project. 

Go streamline! ;-)

Seth

[Aseem Kishore]

Agreed — Bruno is single-handedly the very best open-source maintainer I've ever had the pleasure of working with. Thanks for everything you do, Bruno.

I myself am "guilty" of submitting many feature requests. I've always appreciated that Bruno has always been so open and receptive to them, never making me feel ashamed for asking so much from what's already so awesome.

I'll definitely look to submit PRs for my own feature requests when I'm able to going forward.

I know one thing that'd make me more confident in changes as well is more automated tests "above" the transformation layer. Things like the different require() scenarios Bruno mentions, uses of the command-line options, etc. Perhaps I'll give that a shot when I get some time...

Aseem

--
You received this message because you are subscribed to the Google Groups "streamline.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to streamlinejs...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bruno Jouhier]

Thanks.

BTW, it's not really the streamline issues that overwhelm me. It's actually pretty light so nobody should feel feel guilty about it. It is just that it comes on top of lots of other things. And I'm sure I'm not the only one with a busy schedule!

You're right Aseem, the first thing to do on the differerent compile/require scenarios it to write unit tests.

Bruno

[Greg Slepak]

Sorry if this has been mentioned somewhere already, but have you looked into working with the NodeJS team on integrating streamlinejs into node?

It seems like an obvious evolution of streams to me, and it would be great if the node project itself stood behind it.

- Greg

[Greg Slepak]

One more thing to that: if this is to make it into Node, I would hope that you get rid of the reliance on '_' and make the syntax more natural (as well as the ._js/._coffee stuff).

[Tim Caswell]

On Mon, Jan 20, 2014 at 7:09 PM, Greg Slepak <gr...@kinostudios.com> wrote:

Sorry if this has been mentioned somewhere already, but have you looked into working with the NodeJS team on integrating streamlinejs into node?

It seems like an obvious evolution of streams to me, and it would be great if the node project itself stood behind it.

I'm afraid the interaction with the core team on this issue has been less than friendly historically.  There have been several heated discussions on the node mailing list in the past whenever Bruno recommended streamline to some person asking for async help.

Feelings aside, node-core has a pretty strong stand that it won't change the async model any time soon.  Even now with generators coming to the 0.12.x release, the plan in core is to stick to callbacks as the preferred style and only support the new stuff on the side.

A lot of the reason for this stand is API stability.  Another reason is that those of us who have invested the time to write callback style for years can write fairly complex programs without using streamline or generators.  This makes it harder for us to empathize with people who struggle with callbacks and harder to understand the argument for advocating a build step like streamline into the workflow.

That said, I like Bruno's work.  Even though I have no need for it personally, I can see how it helps others.  Especially code like what's used at sage can benefit greatly from a tool like streamline.

-Tim Caswell

[Greg]

On Jan 21, 2014, at 9:05 AM, Tim Caswell <t...@creationix.com> wrote:

This makes it harder for us to empathize with people who struggle with callbacks and harder to understand the argument for advocating a build step like streamline into the workflow.

I also don't like the build-step, which is why my followup email requested that if this is to be merged into NodeJS (and I think it'd be great if it was), the built-step, and all related special files and underscores, need to be removed.

If NodeJS itself did all that special finagling transparently for you, would you be more likely to use it instead of callbacks?

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

[anodos]

Streamline saved our project and has saved untold time and money besides. I feel a debt and gratitude to the project and would assist if at all possible, though my current employment makes that impossible.

Thanks, Bruno, for everything you do.

[Bruno Jouhier]

Hi Tim,

I was going to answer something along the same lines. Thanks.

I try not to answer too often to the mailing list but I do once in a while because I feel very frustrated when I see all the people struggling and receiving answers like "sorry there is nothing you can do about exception handling - just kill your process and restart it". This is frustrating because there are solutions that work and they have been around for 3 years now (streamline was released Jan 9, 2011 and fibers came out about a week later).

Actually I tend to have some compassion for the core team staying with callbacks these days. There are so many solutions around that it is difficult to pick one. To me streamline is still a stopgap until a really good solution gets blessed by TC39 (the ! syntax sugar of http://wiki.ecmascript.org/doku.php?id=strawman:concurrency gets my vote). The day this happens, I'll run one last transform (a new one) on our code and we'll have clean code that runs on top of the latest and greatest JS async syntax.

Just a side note: streamline does not require any build step. It precompiles the files on the fly and there is also a --cache option which avoids recompiling. Just like CoffeeScript.

Bruno

[Bruno Jouhier]

Hi Greg,

I never use the build option, except to precompile the few files that I distribute with streamline.

Our application uses a loader so we run it directly with node and it precompiles the files on the fly. And when I write single file scripts, I run them with _node.

Bruno

[Seth Pollack]

I agree that the long term solution is most likely standardized async handling within the javascript language itself. (it seems unlikely that leadership on this topic will come from the node team — and understandably so, there are plenty of other issues to tackle.) Once that happens, we can all move on from streamline. but in the meantime, streamline is the best solution i’ve seen. I think there is a good benefit even for developers already experienced with callbacks (that has been our experience). 

I would love to see us collectively get more effective at spreading the word about streamline within the node community. My recent blog post (http://blog.rivaliq.com/develop-double-time-node-plus-streamline/) was one attempt at that. Perhaps talks about streamline at the various big node conferences (by Bruno or others)? Other ideas? 

Seth

[Bruno Jouhier]

Greg,

Just a quick word on removing the underscores: it is a easier said than done. To be able to turn sync-style code into something that executes on top of async APIs you need to be able to distinguish between sync and async calls. Streamline uses an underscore for that but if you don't like this you'll need something else! There is no absolute magic that will make this completely transparent.

I chose to do this by reserving one identifier rather than by extending the language grammar. This may sound like a hack but it has plenty of advantages. For example it makes it very easy to use streamline with existing linters, code formatters, syntax colorizers, etc. It also made it very easy to piggyback the streamline transform behind CoffeeScript, etc. (and the recent emscripten+streamline vim port is another killer example). Overall this is a design choice that I did not regret a single day.

Bruno

[Bruno Jouhier]

Hi Seth,

I'd be happy to speak about it. I'm not routinely travelling to the US (about once every 18 months) but I can arrange something for a node event as I'm working with US teams (Irvine). Next trip will be Miami in March but this one will be for vacation.

A big node event would also be a great opportunity to meet in person.

Bruno

[Bruno Jouhier]

Thanks anodos.

[Seth Pollack]

That would be fantastic!

[Alexey Petrushin]

The conflict because there are different goals, core - to build small, simple and fast IO framework, product builders - high development productivity.

No need to argue, just use node.js as a basic layer and put what else you need for productivity on top of it.