phpnode

yep!

same mechanism, just deal with more edge cases. e.g. whitespace isn't really trimmed correctly at the moment, it doesn't handle escaping quotes in strings and so on. I did think about trying to match postgres's grammar but it's a lot of work and probably implementing a PEG first would make it easier.

oh let's be clear there's no sensible real world use cases of this thing. it's a demonstration of what TS's type system can do

it's a bit fragile only due to my laziness, it could be done properly if this were a serious project.

> The implementation isn't even that horrible

You're making me blush!

The list of integers could be replaced by using tuples and reading their lengths to do basic arithmetic. Might run into recursion limits though.

hover over the type annotations to see results in the playground, that's the output :)

The errors aren't really errors, just warnings about unused types

I used to be a big fan of the idea of schema.org, but it seems to be used by Google to keep as much traffic as possible on Google properties.

Writing an alternative babel plugin to do the transform this way would be pretty trivial, but doing so for TypeScript is not (officially) possible. TS is going to choose one and it's going to be the one React uses.

Also the decision to split React's createElement() into jsx() and jsxs() means that to maintain compatibility all libs would have to do the same, and provide both functions, all because of an implementation quirk in React.

JSX should be a standalone thing. It's not intrinsically React, and shouldn't bend to React's needs alone.

It can be done if you write your code like this:

    function MyThing() {
      return (
        el(A, {value: 123}, [
          el(B, {value: 456, foo: true}, [
            el(C, {awesome: true}),
            el(D, {awful: false})
          ])
        ])
      );
    }

but there's a reason people prefer JSX syntax

JSX is a tree of deferred function calls. It's nothing to do with HTML, despite them looking similar. Normal function calls are not equivalent

This is a missed opportunity to make JSX more than solely about UI and I'm pretty disappointed about it.

JSX is really a way to describe a hierarchy of deferred function calls independent of their callers. This could be tremendously useful in a number of different contexts, not just UI. What would a state machine look like if the states could be described in JSX? What would rx.js look like if this mechanism was available?

The current tooling makes experimenting with possible alternate use cases pretty awkward, and so basically no one is doing work in this area.

I believe that these changes, particularly the `jsx` and `jsxs` auto import, will make it even harder to separate JSX as a concept from React and React-like libraries. It'll make it harder to standardise JSX, which is frustrating as it's the most supported ECMAScript syntax extension by a long way.

My modest proposal is that a JSX element desugars to a call to a block scoped identifier called `jsx`, so I can do something like this:

    import { jsx } from 'react';
    import { elementCreator } from 'somelib';

    const someFunction = () => {
      const { jsx } = elementCreator();

      return <iAmNotAReactElement />;
    };

    const MyReactComponent = () => <div>cool</div>;

Taking this alternative approach would give developers a widely supported syntax extension that could allow for some really innovative solutions. The current path is going to do the opposite.

I understand that there are perf optimisations that React can do if they control all of this. But I feel like they're looking at this too narrowly, from only the perspective of UI. They have the power to open up a lot more opportunities.

What's motivating your hostility in this thread?

Larger and with more features, but ultimately lacking the simplicity and elegance of the much older version?

> There's no portion of the code that does warmups.

This isn't true - Benchmark.js will repeatedly rerun benchmarks until it gathers statistically meaningful results.

> There's no portion of code that "blackholes" the results to keep the JIT from optimizing away the code under benchmark.

True, and there's actually nothing benchmark.js can do to ensure that doesn't happen in the general case but when this does happen the results are usually pretty obvious - we'd see billions of ops/sec. Incidentally the left-pad benchmarks do not suffer from this issue.

The US is actually at number 17 in the list of milk consumption per capita: https://en.m.wikipedia.org/wiki/List_of_countries_by_milk_co...

I really feel like default exports were a mistake, everything is simpler without them, they don't even work with things like `export * from './foo'`

I'm not sure what you're asking, the tools are there for you to replicate their experiment.

They provide the matlab code and source inputs for their experiments, you could attempt to verify their results if you don't believe the video.

> is there a word for a computer generated person?

Maybe "infomorph"?

Poverty and deprivation are not post-industrial inventions

The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue 2 microtasks, as promises are always guaranteed to be async. If you remove the process.nextTick the results are reversed, I get:

- 63ms (async)

- 100ms (casync)

so it's almost twice as slow as native async await in this example.

Go's error handling really reminds me of errbacks in node (callback function with a possible error as first argument), with many of the same pitfalls. I wonder why so many people defend Go's choices here in comparison?

You just don't need to spend that much, it would be grossly overpaying.

This is pure fantasy, who would spend $250m to acquire a stolen painting that they cannot resell? If it really is rich people buying them the purchase price is going to be a fraction of a percent of the amount you're talking about.

the concept of promises as used in JavaScript comes from E

* Tory Bruno[0]

[0] https://en.wikipedia.org/wiki/Tory_Bruno

airlines are already dumping staff, and that's the tip of the iceberg.

I said he was awarded the OBE because of his work in this area, not that an OBE is solely a reason to trust his opinion. He is far more qualified than the growth hacker / marketing guy who has zero expertise in this area as far as I can tell.

I don't personally think politics are playing a major role in these decisions. UK elections are 5 years away, that's a lot of time for them to change the narrative if things don't end well.

They'll restock tomorrow and a large proportion of people who saw the empty shelves today will buy more than they would normally to make sure that they don't go without, leading to empty shelves, goto 10.

Supply chains are intact but they can't deal with this level of demand immediately and so there's going to be a period in which there are shortages. How long those shortages last depend not only demand but on other factors, e.g. how many people in the supply chain are directly or indirectly affected by the virus.