Michael,
You are not alone in your frustrations. Many of your points are valid,
have been voiced before, and will no doubt be voiced again. No one on
here is unsympathetic to this, and many members of TC39, as well as
other community members, dedicate significant amounts of time, freely,
to educational resources.
Lambasting TC39 for not formalizing and centralizing these educational
resources -- a task that exists far outside of their charter -- is not
productive.
The list of useful resources out there is pretty extensive, and as
you've pointed out, that can have a downside if you don't know where
to go. If it's helpful, here's a non-canonical overview of some of the
more useful ones, though:
*/For a one-stop shop:/*
MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you
want a single destination, choose this one. It has introductory
material, beginner, intermediate, and advanced-level tutorials, and is
the most complete and well-maintained developer-focused JavaScript
reference site.
*/For non-formal discussion of cutting-edge, emergent features:/*
*/
/*
Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some
of your specific questions, there is a lot of great material here on
Promises in particular.
Dr. Rauschmayer has also written a series of extraordinarily useful
books that he has graciously made freely available online, here:
http://exploringjs.com/.
*/Regarding the "closed" nature of TC39:/*
*/
/*
Most discussion happens here on this mailing list, in public. Copious
meeting notes for all in-person meetings are available here, as well:
http://tc39.github.io/tc39-notes/.
*/If you want to search past es-discuss threads:/*
*/
/*
https://esdiscuss.org/
*/For "why doesn't this code work?" or "how do I do this?" questions:/*
*/
/*
StackOverflow (https://stackoverflow.com/). Still the gold standard
here, IMO.
*/For your specific questions about why we have Promises AND
Generators AND Iterators AND.../*
*/
/*
The General Theory of Relativity (https://github.com/kriskowal/gtor/).
You obviously already mentioned this, but I encourage you to please go
and read it. While this isn't a general resource for the language, it
is the most comprehensive and useful exploration of this specific
topic that I'm aware of, and I genuinely believe you would find it
illuminating on why this complexity exists around asynchrony.
There are clearly many in addition to these, but that's a short list
of some that I've personally found to be useful.
------
If you don't like that this all exists as discrete, separate
resources, then that's an opinion that you're entitled to. A
canonical, comprehensive, and centralized resource for all of this
would required thousands of hours, either volunteered or paid for by
others, and that's something no one is entitled to. If you want to
make that happen, I suggest a strategy other than reprimanding a group
of people that are already contributing significant time to what
resources do exist.
Regarding topic appropriateness for this mailing list, admittedly the
lines can be blurry at times. GUI's and developer tooling are
typically outside of scope, though. Visualizations around Promises are
an interesting topic, but as a non-TC39 member, I think I can still
safely say that it won't be making it into the language itself.
Tooling is best left to evolve independent of the language itself,
rather than being frozen at the specification level. Even the most
basic developer tools, like the `console` object, are not a part of
the ecmascript spec - they are host objects provided by the runtime.
Again, I'm not trying to be dismissive of your ideas here, but the
validity of an idea or a frustration isn't the measure for whether or
not it's on-topic for es-discuss. If you want to continue discussing
some of your ideas for the language, I'm not discouraging you from
that, but I /am/ encouraging you to perhaps choose one to start with,
evolve the idea until it's sufficiently clear and concrete to present
for discussion.
On Wed, Nov 8, 2017 at 9:00 AM, Michael Lewis <[email protected]
<mailto:[email protected]>> wrote:
How difficult is it for a web developer to make a website?
What if everyone in this mailing list shared their personal
websites, and we ranked them? Not that mine is great, but at
least I'm admitting that it's really fucking hard to make a simple
website... I know a *lot *of web developers that *don't have their
own website*. And most that do, probably used WordPress, a static
site generator, or another crutch.
I was reading a post by Jake Archibald
<https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/> the
other day, and noticed he had some interactive elements within the
content of his page. Wow, what a concept, right? Besides some
major news outlets, I very rarely see this on the web. Aside from
an image (non interactive) or a video (hardly "interactive"), how
often do you see *interactive content* on the web? Very rarely.
How long did it take to create? Jake says he spent his entire
weekend on that one blog post.
*THE WEB IS BROKEN. FOR CHRIST'S SAKE. *And yes, I understand
that nobody in this mailing list cares. Maybe I need to join the
whatwg group, and yell at them. Or maybe I just continue working
on it, by myself, in my basement. Or maybe I'll get some help
someday. Lead me, follow me, or get the fuck out of my way.
*
*
Also, this is a fitting time to share a page
<https://lew42.com/test/view42/View1/Clean/> I wanted to share a
while back (due to Jeremy Martin's inability to imagine a visual
development experience). It doesn't live re-evaluate the code for
each block, as it could. But it shows some object renderings. If
you scroll down to the last test block, and click on the object
titled "this", you'll see a rendering of the actual Test object.
You can see the 1 line of code used to render that:
View.inspect(this, "this");
So yes, Jeremy, you could "automatically render Promise
diagrams"... Maybe I'll get around to showing you how that works.
What does your app *look like?* Creating views for all the things
is really important. If you can see it, you can understand it.
On Wed, Nov 8, 2017 at 7:39 AM, Michael Lewis <[email protected]
<mailto:[email protected]>> wrote:
So, the group that designs the language that the world uses
for building web apps, cannot provide insight as to why they
do what they do? Smells like bullshit. Maybe you can expand
on that part further?
Check this <https://github.com/tc39/agendas/issues/272> out.
It seems the ECMA/TC39 group is closed to the public.
I'm just trying to make this easier for everyone...
This reminds me of our government, who writes laws so dense
even the lawmakers don't read them. And then they expect
everyone to abide by them. It's /somewhat/ understandable
(given the complexity of life). Yet, there's an easy/obvious
solution: summarize, organize, and simplify. The
law/specifications can be complex and simple, at the same
time. And I feel like it's the responsibility of those who
understand it the best to accurately reduce the complexity
into simpler form.
This process (organizing, summarizing, simplifying) is the
ultimate key to life. Science, education, content,
knowledge... Sometimes we do this, but it can always be done
better.
Have we taken JavaScript knowledge, and organized, summarized,
and simplified it to its purest form? Absolutely not. Not
even close.
In some areas of JS development (such as module management
(dep mgmt, loading/import), version control, debugging,
persistence, etc) the /best/ solutions that we have, are
*severely broken*, *have been broken for decades*, and *TC39
isn't concerned with*. That sounds like a problem to me. I'm
sure everyone here would like to argue with me about this.
The point is to realize where these areas *can be better*, and
*make them better*. Not to argue about why they're not
broken... Duh.
But, it seems like we need a new umbrella organization that's
allowed to discuss the entire picture. Hahaha... it's so
stupid. "Don't talk about that here." "That's not a problem,
you're the problem." So much broken.
On Wed, Nov 8, 2017 at 6:49 AM, Naveen Chawla
<[email protected] <mailto:[email protected]>> wrote:
Hi Michael! TC39 is rightfully reluctant to offer usage
advice. People should develop their best practices from
experiences and the use cases they're involved in.
For me, to answer your question, since I'm not a TC39
member, it's async functions all the way, and ditch
observables, raw promises, callbacks. I'd love to hear
from those who think observables might ever be preferable
over using async functions to do the same thing... since I
don't currently see how it could ever be
On Wed, 8 Nov 2017 at 17:56 Michael Lewis <[email protected]
<mailto:[email protected]>> wrote:
Hi Felipe,
I read and generally understand your points (while I
don't fully understand all the new async syntax and
best practices
<https://stackoverflow.com/questions/47178411/custom-thenables-can-i-create-my-own-objects-with-a-then-method>).
You agree that there's a lot to learn, but nobody
wants to even acknowledge that this committee has the
power (responsibility?) to fix that problem
<https://esdiscuss.org/topic/web-docs>. To make
learning simpler, easier, etc. It could start with an
official blog. There are too many scattered
resources. Too much conflicting advice, and not an
official direction.
If Babel is here to stay - and transpiling custom
syntax into official syntax is going to proliferate,
this problem will only get worse.
This has to do with leadership - there doesn't seem to
be a strong presence leading the pack. There are
millions of developers scrambling to make sense of all
this stuff, and the best resources we have are the
continuous stream of blog posts that are constantly
introducing new things, and often create more
questions than answers.
It's clear to me that the people in this mailing list
tend to stay at the cutting edge. You all read about
the latest immediately when it's released. It makes
sense to you, and there is no problem. The "rest of
us" who struggle just aren't doing it right.
On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de
Moura <[email protected]
<mailto:[email protected]>> wrote:
Hi.
Michael, the JavaScript (and Web in general)
communities are very open and always queen to help.
I just think you hit the wrong mailing list to
discuss all that.
For new comers, indeed, there is plenty to work
on, practice and study. But keep in mind that many
of those features came from different languages
and technologies.
And there are a lot of conferences, meetups,
groups, slack channels, newsletters, articles,
videos...tons of content out there :)
Trying to answer your question.
I understand the feeling you are having, but think
it this way...
- Asynchronous code opens doors for possible gains
in performance. Many improvements have only been
possible due to this asynchronicity.
- Async code helps you modulate/split your code.
If your are an organized person, it will be
good...otherwise, things can get messy!
- Async code nowadays can be dealt with, as if it
was sync (using async await), the other way around
was a problem! Many times you needed something
asynchronous and had to create layers on top of it.
- Async allows new APIs. For example, Web workers
and Service Workers. They simply wouldn't be
possible if not by asynchronous ways.
- Creating async APIs allows developers to explore
and use your API in different ways...also, if your
code is well organized, it has an easier maintanence.
- APIs related to interoperability and usability
also benefit from this. Let's say, you need a user
permission to do something and have to way for the
user to agree with it. Or maybe you ware waiting
for another app to answer with the result from
something else, like a picture or a share(from
shareAPI).
As for "which" way you want to make your code
async...that goes with what you are working on.
If you are using promises, you can easily** have
it working with async/await.
Observables and promises can work together, but
you will have to study a little further to feel
familiar with it.
I hope I have helped somehow :)
On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis
<[email protected] <mailto:[email protected]>> wrote:
Making things simpler, clearer, and more
visual has obvious benefits.
I think I was very clear from the beginning
that this was *NOT* a concrete proposal. And
I've seen many posts on here that are not.
From now on, I'll title my posts to more
clearly indicate that *reading is abstract,
discussion, optional.*
*
*
The confusion about async interoperability
<https://medium.com/@benlesh/rxjs-observable-interop-with-promises-and-async-await-bebb05306875>
isn't
mine alone. I'm a new comer to this scene, and
my original curiosity was this community's
long-term vision for asynchrony. How do we get
all the pieces to play well together? Thank
you for contributing 0 to that understanding.
And my point about the new comers to
JavaScript or computers in general, how are
they to make sense of this ever-moving
language? You need better documentation,
publication (an official blog), etc.
On Tue, Nov 7, 2017 at 3:03 PM, Jeremy Martin
<[email protected] <mailto:[email protected]>>
wrote:
Michael,
You've spent a considerable amount of time
putting your thoughts into writing, so I
don't intend to be dismissive of them, but
this doesn't seem to be the right
distribution channel for whatever you're
getting at.
As it stands, you've thrown quite a few
questions out that don't seem to be
related to the ongoing standardization and
specification process that this group is
primarily focused on. E.g.,
* Are RxJS Observables basically streams?
* What will our children be learning in
100 years?
* What are generators?
* ...do they work with Promises?
* ...do they work with streams?
* etc.
There are reams of documentation,
articles, and guides that delve into these
topics in great detail, including the
excellent /General Theory of Reactivity/
that you already mentioned. The questions
you've brought up are all valid, and these
resources will help you gain the knowledge
you need if you still want to put a
specific proposal forward -- but for now
your points seem to awkwardly highlight
that you've already identified the best
resources to do this, but refuse to
actually read them.
And while es-discuss is indeed an
appropriate place to solicit feedback on
language-level proposals, the ideas you've
thrown out read like an off-the-cuff
stream of consciousness:
* Promises that automatically render
diagrams?
* A GUI for loading/defining modules
(somehow related to an AST)?
* Async strings with some informal
behavior around branching and
transforms, that are someone analogous
to version control, and again, a GUI
is involved somewhere?
* Real-time booleans with change events
(but with a new definition for "change
events" that is oddly based around a
non-reactive datastructure).
I made an honest attempt to make it
through your posts with an eye for what
your point is, but these simply aren't
concrete or coherent enough to facilitate
a conversation, much less be actionable.
The concept of "do it now" or "do it
later" is as easy as 123.
I urge you to consider that statements
like this belie that you haven't grappled
with the subject matter enough. It frankly
trivializes the topic beyond recognition.
If you have a concrete proposal you'd like
to see discussed, then a dedicated thread
with a clear description, examples, and
motivating factors is completely welcome.
If you're looking to rant or ruminate
around topics like Promises, Generators,
Observables, Streams, etc., while
simultaneously admitting that you aren't
taking the time to understand them, then
this is simply the wrong venue.
On Tue, Nov 7, 2017 at 3:13 PM, Naveen
Chawla <[email protected]
<mailto:[email protected]>> wrote:
Correct, `for..of` instead of `forEach`
On Wed, 8 Nov 2017 at 01:21 Logan
Smyth <[email protected]
<mailto:[email protected]>> wrote:
A nit, but that would have to be
`for (const move of moves) await
doMoveAsync()` since the `forEach`
callback is a normal function.
On Tue, Nov 7, 2017 at 11:47 AM,
Naveen Chawla
<[email protected]
<mailto:[email protected]>> wrote:
... that should be `await
doMoveAsync()`
On Wed, 8 Nov 2017 at 01:16
Naveen Chawla
<[email protected]
<mailto:[email protected]>>
wrote:
async functions create a
new promise for you upon
every invocation, which
you resolve via `await`,
but that's all invisible
in the background. It's
basically:
async function doMovesAsync(){
moves.forEach(
move=>{
doMoveAsync(); //another
async function
}
);
}
...so you can do regular
programming, in async
world. This is why I
believe it's more powerful
than observables, thereby
making them redundant.
When I say branching into
multiple outputs, I do
mean creating new data
that leaves the original
data untouched.
On Tue, 7 Nov 2017 at
20:57 Michael Lewis
<[email protected]
<mailto:[email protected]>>
wrote:
Also, if you've made
it this far, I think
it's worth mentioning
that these async
strings are basically
all you need for a
realtime file system.
File("newFile.ext").append(File("fileA"),
File("fileB"),
...).transpile().save();
// --> automatically
watches, all inputs
(fileA, fileB, etc),
caches unchanged
files, reapplies
transforms, writes to
file...
Webpack and gulp are
basically async plugin
systems w/ transforms.
They're just way too
complicated.
Simplify all the things.
And while we're at it,
why not make a
realtime version
control system? Not
just for files, but
for all the things
(any data structure
inside the app). For
example, if we have
variable strings,
could we enable a
history on it?
Instead of branching
onto a separate
entity/value, could we
branch /within /the
string itself, so that
we have an entire
*verrsion tree *for
any value?
*What are the
fundamental data
structures in computer
science?*
The Boolean,
obviously. The
Integer. The String.
Why not a realtime
boolean? I suppose
that's just a boolean
+ change events. What
is a "change event"?
Just an array of
functions. But
JavaScript functions
are an abstract
concept (compared to
processor
instructions). What do
functions look like at
the processor level?
They're compiled with
all the dependent
values, right? How
many processor ticks
does the average line
of JavaScript use?
I feel like all
languages could boil
down to a very small
set of fundamental
data structures, and
maybe a slightly
larger set of
specialized data
structures.
What are the different
types of circuits in a
process? I understand
(roughly) the basic
logic gates, but is
there specialized
circuitry for
specialized data
structures? What if
those fundamental data
structures were
optimized at the
circuitry level?
What if we can
optimize our programs
to run as nearly
instantly as possible?
Most scripts are
/mostly /instant - at
least, there's no
external input. For
any process that's
/nearly/ instant,
couldn't it actually
be instant? In other
words, 1 tick of the
processor? Load up all
the registers with the
necessary values, and
shine the light down
those
transistors/logic
gates, so that we
arrive at our result,
instantly?
I really feel like
this is possible. Like
I mentioned earlier,
I've never compiled a
lick of code in my
life, and have very
little understanding
of those things. But
from my sense of
JavaScript, it's far
from instant. How
many processor ticks
per line of JavaScript
code, on average?
Is anyone still listening?
On Tue, Nov 7, 2017 at
8:47 AM, Michael Lewis
<[email protected]
<mailto:[email protected]>>
wrote:
I'm not
experienced in
async/await enough
to know what
"using async
functions to
process [streams]"
would look like.
You would have to
create a new
promise for every
iteration? Even if
performance isn't
an issue, it just
doesn't make sense
to me. It's like,
you could use
`obj.value = "my
string"` instead
of `var myString =
"my string"`, and
it will work. And
the performance
difference is
negligible. But,
it just doesn't
make as much sense...
*Branching vs
Mutation*
The point you
bring up regarding
"branching the
stream into
multiple outputs"
is another
fundamental
concept in
programming (that
I'm still trying
to wrap my head
around).
Basically, does an
operation (aka a
method) operate on
the original data,
or fork/branch,
preserving the
original, and
creating a clone
to apply the
transform to.
For example,
arr.push()
manipulates
(mutates) the
original array,
but arr.slice()
branches, giving
you a brand new
array, leaving the
underlying array
untouched (immutable).
This has always
been an area of
confusion for me.
Which methods are
mutators, and
which are immutable?
*Async Strings*
An interesting
away to look at
all this async
stuff, is to
consider strings,
and their
operations
(methods), in an
asynchronous way.
How can a string
be asynchronous?
Just let it change
over time, and
broadcast change
events.
What if you
compose a string
with several
pieces:
asyncParentStr.append(asyncStrA,
asyncStrB, asyncStrC).
Each asyncString
can have change
events, and will
propagate changes
to anyone
depending on it.
asyncStrB.set("new
value") will
trigger
asyncParentStr.change()
event.
I feel like this
is fundamental
functionality that
is lacking from
JavaScript. Now
that we have
`const`, shouldn't
`var`
automatically set
up change events
for that "var"?
*Async transforms*
But lets say we do
asyncParentStr.append(asyncStrA,
asyncStrB.replace("hello",
"goodbye"),
asyncStrC).
Now we have the
question: do we
want this
.replace() to be a
"live" transform?
When we
asyncStrB.set("hello
world"), does it
re-apply the
replace? I think
there are many use
cases for both:
mutate the
original
asyncStrB, so that
all references to
this value also
exhibit the
transform. And
also the
alternative, the
immutable,
branching kind of
transform, where
you don't mutate
the underlying
value, and instead
are branching.
This concept is
also the core
concept of version
control: do we
continue down the
same path, or
branch off?
*GUIs will prevail*
You can try and
create different
methods (
._replace() vs
.$replace() ) to
represent
transform vs
branching (I don't
know which looks
more like which).
But, in the end,
the GUI will
prevail. Artists
can dream about
how to envision
these version
trees, and perfect
the
GUI/experience.
The code interface
just can't compete
with GUI, in the
long run.
I suppose, its
necessarily true
that the API
preceeds the GUI.
API before GUI,
but GUI all the
things. That's my
new motto.
*What if variables
were automatically
async, and
referential? *(As
opposed to `const`
that could be the
immutable flavor)**
var str = "hello
world";
str.replace("hello",
"goodbye"); //
transforms `str`
var "in place"
log(str) //
"goodbye world"
str = "hello cruel
world"; //
transform is reapplied
log(str) //
"goodbye cruel world"
This will never
happen, but it
shows the
fundamental
difference in
logic. Both are
logical/useful...
On Tue, Nov 7,
2017 at 8:08 AM,
Naveen Chawla
<[email protected]
<mailto:[email protected]>>
wrote:
For me the
future is
async
functions (the
present
actually). I
asked a
question about
possible
support for
async streams
/ observables
here:
https://esdiscuss.org/topic/stream-async-await
<https://esdiscuss.org/topic/stream-async-await>
and I realized
that my use
case was much
better served
by just using
async
functions to
process each
input value in
the stream.
I think using
async
functions is
much more
powerful than
"observables",
since it
allows you to
easily branch
the stream off
into multiple
outputs etc.
Using
Promise.all
etc. is also
trivial to use
where desired,
etc.
Furthermore,
async
functions
allow
while/for
loops that
include other
async function
calls, and
this looks
like
programming
with regular
functions, so
it's trivial
to set up
asynchronous
iteration,
and/or
infinite event
processing,
etc., even
without the
new "async
iteration"
proposal.
On Tue, 7 Nov
2017 at 17:25
Michael Lewis
<[email protected]
<mailto:[email protected]>>
wrote:
The email
wasn't
about my
kids, and
you don't
have to
read it
(duh). If
your time
is so
valuable,
maybe you
shouldn't
be picking
fights
with
rambling
parents.
Where is
the list
of
approved
topics?
On Tue,
Nov 7,
2017 at
5:44 AM,
Bob Myers
<[email protected]
<mailto:[email protected]>>
wrote:
I'm
confused.
You
don't
have
time
to
read
"The
General
Theory
of
Reactivity",
yet
(1)
you
have
time
to
write
this
long,
rambling
email
about
your
kids,
and
(2)
expect
people
on
this
mailing
list
to
spend
their
valuable
time
reading
it?
Please
stay
on
topic
for
the list.
Bob
On
Tue,
Nov 7,
2017
at
4:48
PM,
Michael
Lewis
<[email protected]
<mailto:[email protected]>>
wrote:
Good
morning
JavaScript
world,
Maybe
I'll
start
my
mornings
with
a
cup
of
coffee,
and
a
discussion
prompt.
We'll
see
how
long
it
lasts.
It's
4:39am.
I
live
in
Aurora,
Illinois,
about
an
hour
outside
of
Chicago.
My
kids
will
wake
up
in
an
hour
or
two,
so
I
don't
have
long,
and
should
be
working
on
my
framework
anyway.
*So
much
asynchrony*
There
are
callbacks,
promises,
async/await.
We
have
streams
in
node.js.
There
are
libraries
like
RxJS
for
Observables
(that
are
basically
streams?).
What's
the
end
game?
What
will
our
children's
children
be
learning
in
100
years?
Let's
reduce
these
pieces,
distilling
them
into
their
simplest
components.
This
<https://esdiscuss.org/topic/promises-vs-streams> is
an
interesting
thread
(from
es-discuss)
regarding
asynchrony,
which
references
Kris
Kowal's
General
Theory
of
Reactivity
<https://github.com/kriskowal/gtor/>,
which
is
too
long
for
me
to
dig
into
at
this
point
in
my
life.
The
disappointing
part,
is
that
this
community
(who
has
mastered
asynchrony)
doesn't
feel
like
there
are
any
shortcomings,
and
so
we
continue
onward
without
fixing
the
mess.
Oh,
and
generators?
I
don't
fully
understand
these
things.
Do
they
work
with
promises?
Can
you
use
a
generator
to
process
a
stream?
How
do
generators
work
with
or
compare
to
async/await?
Who
knows...
I
think
it's
safe
to
say
that
asynchrony
is
a
confusing
mess.
*But
it
shouldn't
be.
*The
concept
of
"do
it
now"
or
"do
it
later"
is
as
easy
as
123.
Recently,
I
read
through
Jake
Archibald's
JavaScript
Promises:
an
Introduction
<https://developers.google.com/web/fundamentals/primers/promises>.
I
really
enjoy
Jake
Archibald's
writing.
He
makes
JavaScript
less
boring.
But
wow,
understanding
promises
in
their
full
depth
is
really
complicated.
Sure,
a
simple
promise
is
more
or
less
a
callback,
easy
peasy.
But
once
you
start
composing
parallel
and
series
tasks,
add
error
handling,
and
try
to
understand
the
control
flow
-
it's
a lot.
I
feel
like
Promises
could
automatically
*render
a
diagram
*when
using
them.
In
Jake's
very
practical
example
(request
a
list
of
chapters,
load
all
chapters
in
parallel,
then
append
them
to
the
page
in
order)
there's
a
lot
going
on,
to
say
the
least.
Wouldn't
it
be
nice
to
see
a
diagram
of
these
tasks?
A
timeline
maybe?
Imagine
debugging
a
complex
sequence
of
async
actions.
And
you
have
no
idea
which
piece
is
failing.
Using
the
console
to
log
values,
and
trying
to
step
through
the
code
with
the
debugger
are
two
of
your
basic
approaches.
But
honestly,
neither
of
these
really
/show
/you
what's
going
on.
Chrome
Dev
Tools
has
an
awesome
timeline
GUI.
I've
spent
an
hour
here
or
there
tinkering
with
it,
but
can't
make
sense
of
a
lot
of
it.
There
are
100's
if
not
1000's
of
very
generic
blocks
that
show
up
on
the
timeline,
that
don't
clearly
identify
what
they
are.
And
I
don't
believe
there's
any
way
to
visualize
promises
on
this
timeline.
*The
problem
with
Promises*
I
want
to
create
a
file
system
framework
for
node.
I'd
like
to
make
watching
the
files
for
changes
a
default
feature.
The
problem
with
promises,
is
that
you
can't
re-resolve
them.
So
I'm
basically
left
with
streams,
or
plain
old
callbacks.
Or
trying
to
recreate
the
promises
every
time
they
resolve...
What's
the
end
game?
100
years
from
now?
Frankly,
this
is
the
most
important
question.
I
feel
like
if
we
take
a
step
back,
and
try
to
solve
these
problems
for
the
long
term,
we'd
be
better
off.
And
so,
it's
5:15.
Well
done,
Michael.
Well
done.
*The
Future*
If
anyone
has
made
it
this
far,
I'm
going
to
tell
you
a
quick
summary
of
my
plan:
1. make
an
ultra-simple
web
framework
(almost
done?)
2. use
that
framework
to
make
a
CMS
to
kill
WordPress
3. turn
that
CMS
into
a
web
OS
that
does
everything
a
real
OS
can
do,
only
better
4. turn
that
web
OS
into
a
real,
bare
metal
OS
5. make
lots
of
amazing
(useful)
software
(like
photoshop,
blender,
after
effects,
CAD,
etc)
Software
development
is
sluggish.
Most
software
is
painful
to
use.
Windows,
Photoshop/Illustrator,
many
websites...
Open
source
software
doesn't
get
the
funding/momentum
it
needs
to
really
kill
these
proprietary
alternatives.
We
need
to
change
that.
I'm
going
to
change
that.
Stay
tuned.
_______________________________________________
es-discuss
mailing
list
[email protected]
<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss
mailing list
[email protected]
<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected]
<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected]
<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
--
Jeremy Martin
661.312.3853 <tel:%28661%29%20312-3853>
@jmar777 <https://twitter.com/jmar777> /
@j <https://stream.live/j>
_______________________________________________
es-discuss mailing list
[email protected]
<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected]
<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
--
[ ]s
*
*
*--*
*
*
*Felipe N. Moura*
Web Developer, Google Developer Expert
<https://developers.google.com/experts/people/felipe-moura>,
Founder of BrazilJS <https://braziljs.org/> and
Nasc <http://nasc.io/>.
Website: http://felipenmoura.com
<http://felipenmoura.com/> / http://nasc.io/
Twitter: @felipenmoura
<http://twitter.com/felipenmoura>
Facebook: http://fb.com/felipenmoura
LinkedIn: http://goo.gl/qGmq
---------------------------------
*Changing the world* is the least I expect from
myself!
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
