any plans to align more with es6/es7 standards?
37 views
Skip to first unread message
Darren Cruse
Nov 8, 2015, 9:18:00 AM11/8/15
to StratifiedJS
Hi I'm a newbie to stratifiedjs - I looked at it a few years ago when it was "oni apollo" but I just watched the intro screencast and I really like what I see now (I'm not sure how much of that is stratifiedjs having changed versus *me* having changed :) - I'm deeper into js now than when I'd looked before).
My biggest doubt about what I'm seeing in stratifiedjs is not with stratifiedjs itself per se. But doubts whether I could get others I work with to see what I see and go with it.
i.e. the buzz in the more corporate type environments I'm encountering seems mostly around angular (first) and then es6/es7 standards (second). And those two examples seem to highlight the two yardsticks for adoption I always see - either something's already wildly popular and so has a huge community (angular) or else that it's a sanctioned standard (es6/es7).
So I'm wondering are there any plans for stratified to:
a. adopt the es7 asyc/await keywords? (maybe that's a dumb question - am I seeing stratified doesn't *need* such keywords?)
b. use the es6 template literal syntax? (stratified looks close already but didn't I see #{x} not ${x})
c. use the es6 module syntax?
d. use es6 generators for the stratifiedjs streams?
e. es6 style arrow functions (i.e. (x) => {...} ) in place of the ruby style blocks? (i.e. {|x| ...})
(I see there's coffeescript style arrow functions i.e. -> I might not be appreciating the difference yet between the arrow functions and the blocks)
Thanks and stratifiedjs really does look good to me (I've been tinkering with enough of with alternatives - generator based task runners, the js-csp channel approach, react and angular, etc. - to recognize the value of what's here).
It just seems stratifiedjs might be an easier sell to coworkers if it was closer with these standards.
Darren
Alexander Fritze
Nov 9, 2015, 1:44:54 AM11/9/15
to strati...@googlegroups.com
Hi Darren,
[...]
decision. SJS 'solves' one particular class of problems in web apps
elegantly, but of course comes at a price (new syntax, another
dependency to worry about, etc...)
> i.e. the buzz in the more corporate type environments I'm encountering seems
> mostly around angular (first) and then es6/es7 standards (second). And
> those two examples seem to highlight the two yardsticks for adoption I
> always see - either something's already wildly popular and so has a huge
> community (angular) or else that it's a sanctioned standard (es6/es7).
For the past couple of years we've mainly focussed on building a
complete "isomorphic" client/server framework around SJS (see
https://conductance.io or
http://www.infoq.com/presentations/real-time-app-stratified-javascript
- both of these are somewhat out of date unfortunately; only our
github repo is up to date atm; a new release is a few months away). I
think SJS only really unfolds its full potential in this full-stack
scenario.
Most of our recent design decisions in SJS are a direct result of what
we've learned building this framework and applications on top of it.
In particular we're trying to find "universal" abstractions: Rather
than having different domain-specific languages for UI / DB and
everything in-between, we're trying to make SJS expressive and
compositional enough so that a small number of primitives work in many
different problem areas.
Consequently, compatibility with upcoming ECMA standards has taken a
bit of a back seat. We *do* want to be as compatible as possible, but
it just hasn't been a priority lately (especially given that ES6 is
not available on all of our target platforms yet).
There are a few features in ES6 & ES7 that we definitely want in SJS
sooner rather than later (things like the 'spread (...) operator').
In some cases we have added features that diverge somewhat from the
standard (e.g. our template literal & arrow syntax is a bit different
to ES6) and - while I believe in most cases we have found a 'better'
(i.e. more practical) syntax sweetspot - we could be swayed to align
with the standard if there were demand for that.
> So I'm wondering are there any plans for stratified to:
>
> a. adopt the es7 asyc/await keywords? (maybe that's a dumb question - am I
> seeing stratified doesn't *need* such keywords?)
Not a dumb question at all - but yeah, SJS doesn't need async/await.
In a way, in SJS *every* function is automatically 'async' and every
function call is automatically 'await'.
While async/await is a great improvement over the current situation in
JS, it feels very strange when you come from SJS programming. Whether
a function is asynchronous or not is just one of many traits that a
function can have. E.g. a function can be side-effecting or pure. It
can be idempotent or not. Etc. We don't have to annotate functions
with these other traits, so why should asynchronicity be somehow
'special'?
> b. use the es6 template literal syntax? (stratified looks close already
> but didn't I see #{x} not ${x})
We *do* have a simplified version of template literal syntax that
omits the optional tags of es6's syntax. Templates (or 'quasis' as we
call them in SJS) are e.g. used for HTML in our conductance framework
(see e.g. the examples on https://conductance.io/).
Omitting the tags was a conscious decision - it seems gratuitous
special syntax, as normal function calls can pretty much play the same
role.
(#{x} is for interpolation in *strings* btw - ${x} is for
interpolation in quasis)
> c. use the es6 module syntax?
This is a tricky one. 'export foo' as an alternative to 'exports.foo =
xxx', yes. 'export default' and the full 'import' syntax probably not.
>
> d. use es6 generators for the stratifiedjs streams?
No, unfortunately generators aren't powerful enough to implement the
implicit resource management that sjs streams have (and neither is
async/await).
E.g. in SJS a stream of the lines of a file could look like this:
function lines(file) {
return Stream(function(downstream) {
var handle = fopen(file);
try {
while (!is_eos(handle))
downstream(read_line(handle));
}
finally {
close(handle);
}
})
}
When we use this e.g. like this:
lines('foo.txt') ..
transform(line -> line.length) ..
each {
|length|
if (length > 80) {
console.log('warning, line width exceeded');
break;
}
}
Then, if we hit the length > 80 condition, the break will not only
bail out of the block, but also cause the file to be closed (by
implicitly executing the 'finally' handler).
You would think that you could code something similar with generators,
but it turns out you can't - see
https://groups.google.com/d/msg/stratifiedjs/IULlfOt1A6w/cXtBx1byIFYJ
> e. es6 style arrow functions (i.e. (x) => {...} ) in place of the ruby
> style blocks? (i.e. {|x| ...})
> (I see there's coffeescript style arrow functions i.e. -> I might not be
> appreciating the difference yet between the arrow functions and the blocks)
SJS has both -> and => (the fat arrow binding 'this'). They are both
intended for small expression-based functions (and, in constrast to
the ecma standard, the right side needs to be an expression, i.e. must
not contain statements like 'if', 'while', etc).
The idea behind block lambdas is that they behave very similar to
normal JS blocks (a block is e.g. the `{...}` in `while() { ... }`).
In particular 'break', 'continue' and 'return' work in a way to make
it possible to write looping constructs that almost behave like native
'while' or 'for' constructs. Consider e.g. this function that loops
over the elements of an array:
function forEach(arr, f) {
for (var i=0; i<arr.length; ++i) {
f(arr[i]);
}
}
With normal functions, we have no simple way of breaking out of the iteration:
forEach([1,2,3,4,5],
function(val) {
console.log(val);
if (val === 3) break; // doesn't work. 'return' doesn't work either
});
With block lambdas, this works just fine:
forEach([1,2,3,4,5],
{ |val|
console.log(val);
if (val === 3) break;
});
> Thanks and stratifiedjs really does look good to me (I've been tinkering
> with enough of with alternatives - generator based task runners, the js-csp
> channel approach, react and angular, etc. - to recognize the value of what's
> here).
Thanks :-)
Cheers,
Alex
--
Alexander Fritze
http://onilabs.com
[...]
> My biggest doubt about what I'm seeing in stratifiedjs is not with
> stratifiedjs itself per se. But doubts whether I could get others I work
> with to see what I see and go with it.
Yeah, whether or not to use something like SJS is definitely a hard
> stratifiedjs itself per se. But doubts whether I could get others I work
> with to see what I see and go with it.
decision. SJS 'solves' one particular class of problems in web apps
elegantly, but of course comes at a price (new syntax, another
dependency to worry about, etc...)
> i.e. the buzz in the more corporate type environments I'm encountering seems
> mostly around angular (first) and then es6/es7 standards (second). And
> those two examples seem to highlight the two yardsticks for adoption I
> always see - either something's already wildly popular and so has a huge
> community (angular) or else that it's a sanctioned standard (es6/es7).
complete "isomorphic" client/server framework around SJS (see
https://conductance.io or
http://www.infoq.com/presentations/real-time-app-stratified-javascript
- both of these are somewhat out of date unfortunately; only our
github repo is up to date atm; a new release is a few months away). I
think SJS only really unfolds its full potential in this full-stack
scenario.
Most of our recent design decisions in SJS are a direct result of what
we've learned building this framework and applications on top of it.
In particular we're trying to find "universal" abstractions: Rather
than having different domain-specific languages for UI / DB and
everything in-between, we're trying to make SJS expressive and
compositional enough so that a small number of primitives work in many
different problem areas.
Consequently, compatibility with upcoming ECMA standards has taken a
bit of a back seat. We *do* want to be as compatible as possible, but
it just hasn't been a priority lately (especially given that ES6 is
not available on all of our target platforms yet).
There are a few features in ES6 & ES7 that we definitely want in SJS
sooner rather than later (things like the 'spread (...) operator').
In some cases we have added features that diverge somewhat from the
standard (e.g. our template literal & arrow syntax is a bit different
to ES6) and - while I believe in most cases we have found a 'better'
(i.e. more practical) syntax sweetspot - we could be swayed to align
with the standard if there were demand for that.
> So I'm wondering are there any plans for stratified to:
>
> a. adopt the es7 asyc/await keywords? (maybe that's a dumb question - am I
> seeing stratified doesn't *need* such keywords?)
In a way, in SJS *every* function is automatically 'async' and every
function call is automatically 'await'.
While async/await is a great improvement over the current situation in
JS, it feels very strange when you come from SJS programming. Whether
a function is asynchronous or not is just one of many traits that a
function can have. E.g. a function can be side-effecting or pure. It
can be idempotent or not. Etc. We don't have to annotate functions
with these other traits, so why should asynchronicity be somehow
'special'?
> b. use the es6 template literal syntax? (stratified looks close already
> but didn't I see #{x} not ${x})
omits the optional tags of es6's syntax. Templates (or 'quasis' as we
call them in SJS) are e.g. used for HTML in our conductance framework
(see e.g. the examples on https://conductance.io/).
Omitting the tags was a conscious decision - it seems gratuitous
special syntax, as normal function calls can pretty much play the same
role.
(#{x} is for interpolation in *strings* btw - ${x} is for
interpolation in quasis)
> c. use the es6 module syntax?
xxx', yes. 'export default' and the full 'import' syntax probably not.
>
> d. use es6 generators for the stratifiedjs streams?
implicit resource management that sjs streams have (and neither is
async/await).
E.g. in SJS a stream of the lines of a file could look like this:
function lines(file) {
return Stream(function(downstream) {
var handle = fopen(file);
try {
while (!is_eos(handle))
downstream(read_line(handle));
}
finally {
close(handle);
}
})
}
When we use this e.g. like this:
lines('foo.txt') ..
transform(line -> line.length) ..
each {
|length|
if (length > 80) {
console.log('warning, line width exceeded');
break;
}
}
Then, if we hit the length > 80 condition, the break will not only
bail out of the block, but also cause the file to be closed (by
implicitly executing the 'finally' handler).
You would think that you could code something similar with generators,
but it turns out you can't - see
https://groups.google.com/d/msg/stratifiedjs/IULlfOt1A6w/cXtBx1byIFYJ
> e. es6 style arrow functions (i.e. (x) => {...} ) in place of the ruby
> style blocks? (i.e. {|x| ...})
> (I see there's coffeescript style arrow functions i.e. -> I might not be
> appreciating the difference yet between the arrow functions and the blocks)
intended for small expression-based functions (and, in constrast to
the ecma standard, the right side needs to be an expression, i.e. must
not contain statements like 'if', 'while', etc).
The idea behind block lambdas is that they behave very similar to
normal JS blocks (a block is e.g. the `{...}` in `while() { ... }`).
In particular 'break', 'continue' and 'return' work in a way to make
it possible to write looping constructs that almost behave like native
'while' or 'for' constructs. Consider e.g. this function that loops
over the elements of an array:
function forEach(arr, f) {
for (var i=0; i<arr.length; ++i) {
f(arr[i]);
}
}
With normal functions, we have no simple way of breaking out of the iteration:
forEach([1,2,3,4,5],
function(val) {
console.log(val);
if (val === 3) break; // doesn't work. 'return' doesn't work either
});
With block lambdas, this works just fine:
forEach([1,2,3,4,5],
{ |val|
console.log(val);
if (val === 3) break;
});
> Thanks and stratifiedjs really does look good to me (I've been tinkering
> with enough of with alternatives - generator based task runners, the js-csp
> channel approach, react and angular, etc. - to recognize the value of what's
> here).
Cheers,
Alex
--
Alexander Fritze
http://onilabs.com
Darren Cruse
Nov 11, 2015, 11:05:21 AM11/11/15
to StratifiedJS
Thanks for the detailed reponse Alex. Hoping to find spare time to try more and learn more sjs/conductance in the next week or two.
Re:
For the past couple of years we've mainly focussed on building a
complete "isomorphic" client/server framework around SJS (see
https://conductance.io or
http://www.infoq.com/presentations/real-time-app-stratified-javascript
- both of these are somewhat out of date unfortunately; only our
github repo is up to date atm; a new release is a few months away). I
think SJS only really unfolds its full potential in this full-stack
scenario.
I was just curious does the above mean as I try the current conductance tutorials and examples are there significant differences from this upcoming release?
If so I'm curious about how the new release will differ is there some place describing the changes being made?
And on an unrelated note, right now this is just a hobby level interest for me but if I imagine a day where I did/could use it on a project am I following (from the "License" page of the web site) that it's free as long as it's an open-source for-free non-commercial project.
And that right now the price for using it on a *commercial* project has not been determined? Does that truly mean it's not been determined or does it really mean you guys negotiate such prices per project?
Of course what I'm really wondering is roughly how expensive it might be - on the one hand I could imagine myself using it on a little project of my own let's say on a phonegap style mobile webapp sold in an app store for $1. For such personal projects my budget is pretty limited. :)
But otoh I could imagine it being used on a project for my work, where the budgets are bigger. Yet as we discussed the politics of getting a new tool approved for use honestly make that less likely. So it's kind of a "between a rock and a hard place" kind of thing.
If there's any more info on such pricing details I'd be curious (though it's somewhat premature as like I say I'm just learning right now I don't really have a project in front of me).
Alexander Fritze
Nov 11, 2015, 2:20:36 PM11/11/15
to strati...@googlegroups.com
On Wed, Nov 11, 2015 at 10:05 AM, Darren Cruse <darren...@gmail.com> wrote:
[...]
do still work with some minor changes (e.g. '@TextInput' is now just
called '@Input').
> If so I'm curious about how the new release will differ is there some place
> describing the changes being made?
At the moment, the only truly up-to-date place is the github repo,
https://github.com/onilabs/conductance, and the reference that is
contained therein.
If you have nodejs installed (i think the version needs to be <0.11),
you can get to the reference by doing:
git clone https://github.com/onilabs/conductance.git
cd conductance
make
./conductance serve
and then navigating to http://localhost:7075/doc/
Off the top of my head, the main new features in the upcoming release are:
- an integrated fast key/value store
- bindings to various cloud services (google apis, mandrill) and
management ui to configure credentials
- integrated ssh-client support
- better server api handling that can endure server outages
- many enhancements in the 'surface' ui modules.
> And on an unrelated note, right now this is just a hobby level interest for
> me but if I imagine a day where I did/could use it on a project am I
> following (from the "License" page of the web site) that it's free as long
> as it's an open-source for-free non-commercial project.
>
> And that right now the price for using it on a *commercial* project has not
> been determined? Does that truly mean it's not been determined or does it
> really mean you guys negotiate such prices per project?
>
> Of course what I'm really wondering is roughly how expensive it might be -
> on the one hand I could imagine myself using it on a little project of my
> own let's say on a phonegap style mobile webapp sold in an app store for $1.
> For such personal projects my budget is pretty limited. :)
>
> But otoh I could imagine it being used on a project for my work, where the
> budgets are bigger. Yet as we discussed the politics of getting a new tool
> approved for use honestly make that less likely. So it's kind of a "between
> a rock and a hard place" kind of thing.
>
> If there's any more info on such pricing details I'd be curious (though it's
> somewhat premature as like I say I'm just learning right now I don't really
> have a project in front of me).
The short answer is that currently (until at least version 1.0), you
can have a commercial license essentially for free if you wish (as
long as your project isn't just substantially a repackaging of
conductance/sjs functionality).
The longer answer is that customers who base larger applications on
conductance typically need help/training from us, as well as some
assurances that certain functionality in conductance stays up to date
(such as e.g. our bindings to google cloud datastore). In these cases
we negotiate paid license agreements that contain a support element
and other assurances.
Cheers,
Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "StratifiedJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to stratifiedjs...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[...]
>
> I was just curious does the above mean as I try the current conductance
> tutorials and examples are there significant differences from this upcoming
> release?
The upcoming release mostly adds new features. The existing examples
> I was just curious does the above mean as I try the current conductance
> tutorials and examples are there significant differences from this upcoming
> release?
do still work with some minor changes (e.g. '@TextInput' is now just
called '@Input').
> If so I'm curious about how the new release will differ is there some place
> describing the changes being made?
https://github.com/onilabs/conductance, and the reference that is
contained therein.
If you have nodejs installed (i think the version needs to be <0.11),
you can get to the reference by doing:
git clone https://github.com/onilabs/conductance.git
cd conductance
make
./conductance serve
and then navigating to http://localhost:7075/doc/
Off the top of my head, the main new features in the upcoming release are:
- an integrated fast key/value store
- bindings to various cloud services (google apis, mandrill) and
management ui to configure credentials
- integrated ssh-client support
- better server api handling that can endure server outages
- many enhancements in the 'surface' ui modules.
> And on an unrelated note, right now this is just a hobby level interest for
> me but if I imagine a day where I did/could use it on a project am I
> following (from the "License" page of the web site) that it's free as long
> as it's an open-source for-free non-commercial project.
>
> And that right now the price for using it on a *commercial* project has not
> been determined? Does that truly mean it's not been determined or does it
> really mean you guys negotiate such prices per project?
>
> Of course what I'm really wondering is roughly how expensive it might be -
> on the one hand I could imagine myself using it on a little project of my
> own let's say on a phonegap style mobile webapp sold in an app store for $1.
> For such personal projects my budget is pretty limited. :)
>
> But otoh I could imagine it being used on a project for my work, where the
> budgets are bigger. Yet as we discussed the politics of getting a new tool
> approved for use honestly make that less likely. So it's kind of a "between
> a rock and a hard place" kind of thing.
>
> If there's any more info on such pricing details I'd be curious (though it's
> somewhat premature as like I say I'm just learning right now I don't really
> have a project in front of me).
can have a commercial license essentially for free if you wish (as
long as your project isn't just substantially a repackaging of
conductance/sjs functionality).
The longer answer is that customers who base larger applications on
conductance typically need help/training from us, as well as some
assurances that certain functionality in conductance stays up to date
(such as e.g. our bindings to google cloud datastore). In these cases
we negotiate paid license agreements that contain a support element
and other assurances.
Cheers,
Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "StratifiedJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to stratifiedjs...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages