The only thing I don't like is the fact it's mixed with what's on
discourse.specifiction.org. I post more on discourse.specifiction.org than
on ES-Discuss, meaning I'm more comfortable bothering the people with my
ideas there than on ES-Discuss.
Plainly because it's not always ES related.
On Jun 19, 2015, at 5:12 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
No, thank you.
Email clients are the ultimate forum aggregators.
+1 on “No, thank you. Email works, email has are full-featured clients, do not
force browser use, etc, etc.
—ravi
--scott
OMG Yes please!!!
On Fri, Jun 19, 2015 at 5:04 PM, Axel Rauschmayer a...@rauschma.de wrote:
http://discourse.specifiction.org/t/upcoming-migration/805
Would it make sense to move es-discuss to that upcoming site? I’m not
particularly fond of mailing lists and much prefer forums, especially
http://discourse.specifiction.org/t/upcoming-migration/805
http://discourse.specifiction.org/t/upcoming-migration/805
Would it make sense to move es-discuss to that upcoming site? I’m not
particularly fond of mailing lists and much prefer forums, especially
discourse-based ones.
--
Dr. Axel
No, thank you.
Email clients are the ultimate forum aggregators.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Yes, please. Also if like to take issue with everyone who prefers email
clients for the following reason: it's easier to allow people who want to
keep using email to do so while enabling a richer and more aggressive
experience for those who want it than it is the other way around
On Jun 19, 2015
On Fri, Jun 19, 2015 at 7:23 AM, Scott Sauyet sc...@sauyet.com wrote:
I think the difference between your list and mine exemplifies the tragedy
of the commons as so well described by Mark. Although we both share a
liking for modules and imports, my favorite ES6 feature is the arrow
In the spirit of the discussion about language complexity and
extensibility, consider the following brain-addled, pre-strawman proposal
for a new pick operator.
http://rtm.github.io/boberator.html
I wonder if whatever macro-like facilities make their way into ES 20XX will
be able to handle this.
Someone just brought https://news.ycombinator.com/item?id=9742823 to my
attention. It says:
I like the author’s remarks and philosophy about keeping JavaScript small,
but I thought the opening was remarkably uncharitable. The specific person
and the specific feature are quite irrelevant to the
Discourse has the options to keep the same level of email reporting, daily
aggregation and allowing for responses via mail.
I'm not sure I see the need for a new category there either, there are
already:
- JS
- asm.js
- APIs
- Architecture
There are a fair few structured conversations there that
On Fri, Jun 19, 2015 at 5:12 PM C. Scott Ananian ecmascr...@cscott.net
wrote:
No, thank you.
Email clients are the ultimate forum aggregators.
I'm with Scott. Regardless, this conversation is a non-starter.
Rick
___
es-discuss mailing list
Wow Bob that's really neat. I really like it. Because it returns an object
instead of assigning like destructuring. So it's very useful. So LGTM now
as I kept reading I got a little confused, just give me a moment I will.
But +1 for me. :)
On Sat, Jun 20, 2015 at 12:30 AM, Bob Myers r...@gol.com
This is just a heads up for context that someone published a link to Mark's
post in HN here: https://news.ycombinator.com/item?id=9738866 in case we
get any more new people posting in the thread.
-
Features like classes and `let` are very often criticised and often
languages that did not
Greg McLeod cle...@gmail.com wrote:
I really really love JS (it's so fun!), and while there are many features
in ES6 that I think are great (such as classes, modules, and import syntax)
there are things that quite frankly scare me quite a bit. Such examples
include destructuring and arrow
On 19 June 2015 at 10:06, Alexander Jones a...@weej.com wrote:
If people are unable to internalize the whole language, then surely we
need a way to remove cruft and idiosyncracies in it, lest the language
stagnate beyond repair.
Removing var, typeof, exotic objects, function declarations,
I don't think anyone is frightened about removing these things. The TC
has a commitment not to break the internet, by removing something like
`var` or `typeof` you're disabling *billions* of people who are using the
internet - it would very much literally break the internet. Even if the
TC
If people are unable to internalize the whole language, then surely we need
a way to remove cruft and idiosyncracies in it, lest the language stagnate
beyond repair.
Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
enumerable properties, are just a few examples of things we
An interesting wrinkle in language design has been the rise of
sophisticated linting and style tools like `jscs`. If you wish to
deprecate `var` for instance, it is straightforward to write a jscs module
to enforce that. Further, several large communities (node, wikipedia, etc)
have published
I do not share Mark's view. Contra his sentiment, I was using the small
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to fill
in platform and language deficiencies) leads to a a split in common use
On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell slightly...@google.com
wrote:
I do not share Mark's view. Contra his sentiment, I was using the small
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to
In all of the examples I mentioned there are other, more predictable
alternatives already in the language. Do we really expect JavaScript
programmers in 2025 to remember to use Number.isNaN instead of isNaN? I
really don't understand why people think use strict was OK to pull off,
but further
On Jun 19, 2015, at 10:29 AM, Alex Russell wrote:
I do not share Mark's view. Contra his sentiment, I was using the small
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to fill in
platform and
It sounds like you are advocating for a larger standard library in JS. I
think many on this thread are focusing on whether more syntax features
should be added.
On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell slightly...@google.com
wrote:
I do not share Mark's view. Contra his sentiment, I was
Indeed Mark.
It took some of us longer to unwind those features out of our codebase than
others.
One of my biggest concerns in switching to the yearly numbering system is
the same as Allen Kevin: there will be pressure to ship new features
every year (as if we're a software company that wants
On Jun 19, 2015, at 11:24 AM, Kevin Smith wrote:
ES needs to evolve more rapidly than once every 5-15 years. The yearly
update plan is good, but that doesn't mean we should be rushing proposals
(particularly complex ones) through the process in order to catch the next
yearly release.
use strict was only a breaking change regarding ES3 code that
coincidentally happened to use exactly this literal string as a do-nothing
expression statement in exactly this position. In all of the web, we have
not run across a single incident of this happening accidentally.
For the record, not
On Jun 19, 2015, at 2:53 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 19, 2015, at 11:24 AM, Kevin Smith wrote:
ES needs to evolve more rapidly than once every 5-15 years. The yearly
update plan is good, but that doesn't mean we should be rushing proposals
(particularly
27 matches
Mail list logo
