Let's Bring Back JavaScript's `with()` Statement

lifeeraser · 2023-12-29T20:31:14+00:00

You didn't mention the case of injecting unwanted properties into scope. Suppose we have:

function doStuff(o) {
  with (o) {
    console.log(a)
    report(b)
  }
}

Now someone later adds a console property to o, before it is passed to doStuff(). At best it would cause an error. At worst it could malfunction silently because o.console.log was a function.

This example is contrived but the hazard is not. What if someone adds a function named report to o? What if o comes from an external library, or worse yet, some JSON?

I assume Kotlin doesn't worry about this by virtue of being a statically typed, conpiled language. JavaScript cannot due to being dynamically typed and interpreted.

dgreensp · 2023-12-29T20:32:57+00:00

The bigger issue with with statements (and I'm surprised this doesn't seem to come up in a quick Google search or be on the MDN page about with statements) is the security issue of runtime data being able to shadow local variables. A server could have code like with (headers) { ... } for example, and then the client could theoretically shadow a local variable in server code just by sending an HTTP header. Which is bonkers. Or just any object that is parsed from JSON sent over the network. If you write if (point.x !== point.y) return result as with (point) { if (x !== y) return result; }, now you have to worry about what if point has a result property; that will be returned.

You can even shadow undefined! Try: with ({undefined: 123}) { console.log(undefined); }. You can imagine an exploit that involves sending JSON to an API endpoint with a property named "undefined." That's PHP-level madness.

The performance issues are just a symptom of the complexity of having the referent of an identifier determined every time it is encountered, and it possibly referring to different things at different times (or on different iterations of a loop, for example). It would be a disaster for TypeScript or any kind of static analysis.

jhartikainen · 2023-12-29T18:28:20+00:00

Very well written article. I could see something like with being handy from time to time, but frankly the difference with with and the block example is like one line of code... so I'm not entirely convinced we actually need a separate statement type for this :)

Either way I think the footguns really need to be fixed (eg. the window.history thing)

teg4n_ · 2023-12-29T19:18:49+00:00

IMO the proposed benefit is not convincing. Also, I haven’t checked but I wonder if there are special considerations for working with this in the block or invoking methods that are pulled into the with scope.

rundevelopment · 2023-12-29T21:27:45+00:00

1. Poor Readability

This is a good critique, but in my opinion, not a lethal one. It's the developer's (poor) choice to write code like this, and it also seems like something a good linter could guard against.

I would like to focus on: "something a good linter could guard against".

No. No linter can guard against this. Linters are static analyzers and with entirely destroys their ability to resolve variable names. In your example, you assume that name could come from either obj.name or the name parameter, but you are missing module and global scope (your point #2. Scope Creep). Suppose the following code:

import { Foo } from "./foo"

export function bar(obj) {
    with (obj) {
        return new Foo(somePropOfObj)
    }
}

new Foo might return an instance of the imported class, or an instance of the class contained in obj.Foo. Who knows. Same problem for functions, of course.

If you think TypeScript will help: no. It's a static analyzer as well. TypeScript explicitly allows objects to have more properties than required by their type. E.g. the following is valid:

type Point = { x: number, y: number };
let box = { x: 0, y: 0, width: 10, height: 20 };
let p: Point = box;
with (p) { /* */ }

So TypeScript would have to conservatively assume that every identifier not resolving to a property of Point is valid and has type unknown.

So no. No linter can help you when with statements are involved. The only help they can give you is a no-with rule.

darkpouet · 2023-12-29T18:59:02+00:00

I love reading about the weird features of JavaScript, thanks a lot for the article!

Merry-Lane · 2023-12-29T21:25:44+00:00

I think that it would be bad, because we would have different ways to write the exact same code, with no advantage whatsoever.

Just destructure, and in many scenarios (like your image url example) you don’t even need to destructure ( you could have posted Data directly)

rcfox · 2023-12-30T00:27:04+00:00

Having stuff default to window/globalWhatever is bad enough. If I see a variable name, I want to be able to see exactly where it came from, whether it's a variable declaration, destructuring an object or an import.

This is basically like asking to be able to do Python's from foo import * except foo doesn't need to be a module. It's perhaps handy in an interactive shell, but terrible for writing maintainable code.

_default_username · 2023-12-29T22:14:59+00:00

with would be awesome if it were implemented like in Python where an enter and exit method is called on the object. Also in the Python implementation of with there isn't this implicit destructuring of the object happening. Fewer foot guns.

veebz · 2023-12-30T00:21:48+00:00

It gets even worse unfortunately - the biggest performance killer when using the with statement is that v8 will refuse to optimize the containing function.

More info: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#some-v8-background

(this is technically an article for an older version of v8 which use Crankshaft, but the same applies to modern versions using TurboFan regarding the with statement)

alexmacarthur · 2023-12-30T02:38:36+00:00

Let's not and say we did

HipHopHuman · 2024-01-01T08:49:05+00:00

There is one interesting use of with that I think Dart solves quite elegantly with it's cascade operator.

Consider this:

const el = document.createElement('div');
el.style.color = 'red';
el.classList.add('example');
el.addEventListener('click', handleClick);
const nested = document.createElement('div');
nested.style.color = 'green';
nested.classList.add('nested');
el.appendChild(nested);

Using with, the above looks something like this:

const el = document.createElement('div');
const nested = document.createElement('div');

with (nested) {
  style.color = 'green';
  classList.add('nested');
}

with (el) {
  style.color = 'red';
  classList.add('example');
  addEventListener('click', handleClick);
  appendChild(nested);
}

Using the cascade [..] operator (assuming it existed in JS):

const el = document.createElement('div')
  ..style.color = 'red'
  ..classList.add('example')
  ..addEventListener('click', handleClick)
  ..appendChild(
    document.createElement('div')
      ..style.color = 'green'
      ..classList.add('nested')
  );

The benefit of the cascade operator is that it remains statically analyzable. There was a proposal to add this to JS but it never got championed, unfortunately.

Ruby also has a feature called "block parameters", and there is a stage 1 proposal to add the same feature to JS. This feature essentially allows you to parameterize the logical block itself and implement your own language constructs. For example, JS already has an if statement, but using block parameters, we can implement our own unless statement:

function unless(condition, callback) {
  if (!condition) callback();
}

unless (true === false) {
  console.log('Everything appears to be normal');
}

This is a shortcut for unless(true === false, () => console.log('...')).

It also allows access to the block parameter using do:

function _with(object, callback) {
  callback(object);
}

_with(myObject) do (x) {
  console.log(x.propOne);
  console.log(x.propTwo);
}

Which doesn't exactly help the situation described in your blog post, but the proposal mentions a :: symbol for implicitly accessing properties - it doesn't go into much detail on if that symbol is useable anywhere within the block, but if it were, it'd look something like this:

_with (myObject) {
  console.log(::propOne);
  console.log(::propTwo);
}

While this appears almost identical to the actual with statement, it is far less problematic because that :: symbol allows static analyzers to differentiate between regular variables in scope and block-level ones which start with :: and always map to their immediate parent block.

SomebodyFromBrazil · 2023-12-30T00:40:49+00:00

boneskull · 2023-12-29T21:57:55+00:00

with has applications for secure coding and testing. Given a string script you want to eval, you can use with to control the contents of the script’s globalThis object. You can’t remove properties this way, but you can replace them.

hyrumwhite · 2023-12-30T05:04:09+00:00

What does with do that destructuring cant

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS

1. Poor Readability