Optional Curly Braces in JavaScript

# Ed Saleh (18 days ago)

Hello Everyone,

I would like to propose allowing curly braces to be optional in JavaScript.

Example:

function foo(){
bar()
}

can be written as:

function foo():
 bar()

Or #2:

function foo():
 {bar()}
 {bar2()}

Or #3:

function foo():
 _ bar()
 _ bar2()

Or #4:

function foo():
 - bar()
 - bar2()

Or #5:

function foo():
 ; bar()
 ; bar2()

That would make JavaScript an easy to write on board language, where a language like python dominates because of it's simplicity in writing. This would make JavaScript spread into more areas in science, education and engineering.

Thank you,

# Bergi (18 days ago)

Hello Ed!

That would make JavaScript an easy to write on board language, where a language like python dominates because of it's simplicity in writing. This would make JavaScript spread into more areas in science, education and engineering.

You seem to not only want to make block syntax optional, but rather make whitespace indentation significant. You might want to have a look at CoffeeScript coffeescript.org/#language which is a

compile-to-JS language that uses this concept. Its function syntax is a bit different from what you imagined though, most importantly it doesn't offer any declarations.

kind , Bergi

# Jordan Harband (18 days ago)

My preference would be to make them required in the places they're currently optional :-)

Optional curly braces have led to many bugs, not just in JS (the "goto fail" SSL bug, for example) - why is this risk worth making it easier to write code on a whiteboard, where it doesn't need to be valid anyways?

# kai zhu (18 days ago)

unlike python, many [client-side] javascript programs require rollup/minification into a single dist-file. removing curly braces (just like asi) makes that task more difficult.

this is also why esm-import-statements were a terrible idea. ppl like me would argue frontend-programs (which are mostly non-reusable anyways) should be written as single dist-files from the start rather than as modules -- and why python-programmers make terrible [frontend/ux] javascript-programmers in general.

# Ed Saleh (18 days ago)

Zhu, We can enforce curly braces through "good practice" JavaScript documentation style and eslint style. Making braceless JavaScript feature doesn't make it the best style to use, it just give more flexibility. And yes Jordan, it should actually be enforced to use curly braces in actual coding and that's what I do personally. All I want I want is to see JavaScript as wide spread as Python is. I know the reason why Python is famous today is for this specific reason, as it's easy to write for all types of people.

Thank you all,

# Jordan Harband (18 days ago)

I don’t think the obstacle to JavaScript becoming more widespread is mandatory curly braces, nor do i think any part of python’s popularity is due to optional curly braces.

Separately, how are you measuring “widespread”? One measurement might be, for example, “how many computers is it used on”, and web browsers dwarf most everything else :-)

# Ed Saleh (18 days ago)

I don't see any reason why Python is widely used in math and science, and specially AI, other than this reason. It's easy to write and prototype in.

# Isiah Meadows (18 days ago)

Python is so broadly used in those fields due to good library support, not just ease of language use. But since that discussion is pretty off-topic, I'll leave it there.

# Sanford Whiteman (18 days ago)

I don't see any reason why Python is widely used in math and science…

Should talk to longtime Python peeps about it, it's not just "easy" or they'd be using VB6!

Let me leave this here:

Python has had bignum (arbitrary precision Integers) since 2008.
Even before that, it had Long (not just Double).

V8 (used as a reference for non-browser development) has had
BigInt since... 2018.

— S.

# kai zhu (18 days ago)

Python is so broadly used in those fields due to good library support

javascript in modern browsers has good builtin-api support for most ux-scenarios you can think of. the only thing really missing (and which python has) is a builtin wasm-sqlite3 library (and specialized/secure file-api's to persist sqlite-db-blobs).

then the remaining hard ux-problems like shopping-carts/typeahead-fts-search/million-row-datatables/etc would no longer be hard -- and can even be implemented w/o need of a backend, making "serverless" frontend-apps truly serverless.

# Sanford Whiteman (17 days ago)

the only thing really missing (and which python has) is a builtin wasm-sqlite3 library (and specialized/secure file-api's to persist sqlite-db-blobs).

Browsers (WPWG, not this group) tried WebSQL. It failed because there wasn't a competitive bake-off with any other implementations besides SQLite.

If a browser vendor had used another engine, then SQLite might've won the bake-off and now you'd have what you describe.

# Ed Saleh (17 days ago)

Update to the proposal:

Since we can't make spaces in JavaScript, the best we can do is use '' instead. We will also git rid of ':' after statement in the old version as '' is enough indication and it's more compatible with our current curly braces syntax.

Final result:

if (foo==2) _
bar() _
bar2()

Which is the same as:

if (foo==2)
_ bar();
_ bar2();

Basically _ would allow chaining expressions inside a statement block.

Thank you,

# Ed Saleh (17 days ago)

Update to the proposal:

Since we can't make spaces in JavaScript, the best we can do is use |_` instead.

We will also git rid of : after statement in the old version as _ is enough indication and it's more compatible with our current curly braces syntax.

Final result:


if (foo==2) _

bar() _

bar2()

Which is the same as:


if (foo==2)

_ bar();

_ bar2();

Basically _ would allow chaining expressions inside a statement block.

Thank you,

# Ron Buckton (17 days ago)

The '_' isn't necessary for chaining expressions, as ',' would already suffice:

if (foo==2)
  bar(),
  bar2();

Also, '_' is already a valid expression/identifier.

While I'm not generally a fan of eliding braces from everything, I have expressed interest in evaluating something like C#'s expression-bodied methods for ECMAScript:

class C extends B {
  constructor(arg) => super(arg, true);
  toString() => `prop: ${this.prop}`;
  get prop() => this.x + this.y;
}
# Ed Saleh (17 days ago)

_ is better than , because _ is the closest thing possible to empty space, it could. It could even be represented as empty space when it's written down, and it could come at the beginning or at the end, it's also more appropriate for repeatation, __ is more appropriate than ,,.

# Sanford Whiteman (17 days ago)

The single character

_

is already a valid identifier as Ron said.

And not an obscure one (not that that would matter) but rather the global object used by the Underscore library.

You might as well be using

$

here and trying to convince people to stop using it as the top level of their library.

# Ed Saleh (17 days ago)

How is it a valid identifier? I guess the _ in my case would be used as a statement, not as a function and the JavaScript compiler can somehow distinguish between the different contexts depending

# Ed Saleh (17 days ago)

If it's not possible to get around that, double underscore __ or more _{2,} can be used.

# Ed Saleh (17 days ago)

Any identifier that can implement this feature is great.

# Bergi (17 days ago)

Update to the proposal:

Since we can't make spaces in JavaScript, the best we can do is use '_' instead.

You misunderstood. We could make use of significant whitespace in JavaScript (enabled by the : instead of a brace after a statement) - we just don't want to.

That said, _ is not a workable solution - apart from _ (and any repetitions of it) being a valid identifier already, chaining it like you described doesn't work with nested blocks:

for (const x of [1,2,3])
_ if (x % 2)
  _ console.log('odd')
_ console.log(x)

would be indistinguishable from

for (const x of [1,2,3])
_ if (x % 2)
  _ console.log('odd')
  _ console.log(x)

(and no, please don't suggest repetion of whatever token you come up with for signifying nesting level)

kind , Bergi

# Ed Saleh (17 days ago)

Why you don't want to? I didn't force you to like my proposal. I am just posting my ideas for feedback, not see who wants and doesn't want to like it.

# Ed Saleh (17 days ago)

If it's possible in JavaScript to have :, and enable significant spacing, that would be great.

# kdex (17 days ago)

Note that significant whitespace greatly minimizes the yields of minification as well, which doesn't matter much for languages like Python, but starts to matter as soon as you're forced to send your source code over the network, expecting something to appear on the screen in a few hundred milliseconds. In this sense, this proposal is counterproductive.

# Bergi (17 days ago)

Note that significant whitespace greatly minimizes the yields of minification

Why would it? Nothing would prevent a minifier from changing significant whitespace into braced blocks - just like today, they omit semicolons where possible and remove braces around single-statement blocks.

kind , Bergi

# Ed Saleh (17 days ago)

We can convert the curly braces less style back to curly braces blocks when minifying. We can enforce that style also through linting. Making this new style of using colon spacing for block would be an option to use a certain situations. It basically like if(foo) bar() and if (foo){bar()}. The brace less idea is building on the former. Thank you,

# Bergi (17 days ago)

If it's possible in JavaScript to have :, and enable significant spacing, that would be great.

Why you don't want to?

Your argument for significant whitespace seems to be that the simplicity of Python is great. However, adding an alternative block syntax to JavaScript would fail to achieve this goal, in contrast, it would only make the language more complex.

So no, my educated guess is that it's not possible for you to persuade the wider community and especially the technical committee to accept your proposal. They are very reluctant to add features that don't show a clear benefit.

Since you asked for my personal feedback: JS syntax was influenced by C and Java, and it will consistently keep its curly braces. A different block style would only be a viable choice for a new language or dialect, which should not allow curly braces at all, and would not provide backwards compatibility.

kind , Bergi

# Ed Saleh (17 days ago)

Ok, no problem. I know the committee doesn't add features easily, but starting a discussion is a good first step.

# kdex (17 days ago)

@Bergi: Thanks. This is true only as long as the semantics of significant- whitespace blocks are supposed to stay exactly the same as the semantics of braced blocks. If this proposal is purely syntactical, you are right, but then, I would fail to see the point of this endeavor.

@Ed: Maybe there's a specific use case I'm missing. What were you working on when you got the idea, and how could this feature have benefited you in solving your problem?

# Ed Saleh (17 days ago)

Yes, I know JavaScript is influenced by the C syntax family, which is my favorite style. However, what I pushed for here is kind of merging of 2 programming languages families. We here are talking good attributes from Python and adding it to JavaScript.

# Ed Saleh (17 days ago)

I really like the easy on the eye, readable and simple style of Python and though to bring some of these attributes to JavaScript. People are more inclined to go for readable and less verbose languages.

# Pier Bover (17 days ago)

The TC39 efforts are already quite diluted to add major changes to the language which, no offense, don't really add anything of value.

OP if you really want a whitespaced language for the browser check Imba:

www.imba.io

It's not only a programming language but also a React replacement. It's great and it's really fast.

# Sanford Whiteman (17 days ago)

People are more inclined to go for readable and less verbose languages

You keep saying that's the reason scientific and data-scientific community prefers Python but haven't provided evidence, continuing to sidestep:

● Python's intrinsic support for large numbers

● Python's strong typing

● Python's I/O support

● as Kai mentioned, Python's built-in persistence layer

You might argue that Python's robust scientific library support was merely a consequence of the above advantages, but you can't ignore these advantages.

If I were a research scientist there's no way I would use JS just because it had magic whitespace. It's not the tool for the job. JS doesn't have to worry about being used literally everywhere, it already is used essentially everywhere.

# Ed Saleh (17 days ago)

C# had these feature but still the scientific community went for Python and not C#. JavaScript today has almost all the features python has and more and still it's not as popular as Python for prototyping, algorithms, and AI.

# Sanford Whiteman (17 days ago)

C# had these feature but still the scientific community went for Python and not C#.

C# is a explicitly compiled language. And a Windows language. (Mono is irrelevant, it would be a huge dependency.)

Next?

# J Decker (17 days ago)

On Sun, Nov 3, 2019 at 1:11 PM Ed Saleh <medozs at outlook.com> wrote:

Yes, I know JavaScript is influenced by the C syntax family, which is my favorite style. However, what I pushed for here is kind of merging of 2 programming languages families. We here are talking good attributes from Python and adding it to JavaScript.

Significant whitespace was the worst idea Python implemented. Forced formatting is HORRIBLE. And a lack of braces also makes re-nesting code and evolution more difficult. Neither of these are good things for or from Python.

# Ed Saleh (17 days ago)

I don't like them too but sometimes, their use is more appropriate. Like readability and being less verbose.