> Implying that JavaScript was ever appropriate

Can we please stop doing the 4chan-esque snarky >implying ? It's not discussion in good faith.

> Minifying is highly overrated to begin with

Compression is not magic and minifying has real world performance gains in JS projects at least - I don't see how Python would be different here.

> Lambdas are supported

If you want to write your event handlers - which in UI programming is a lot of your code - in a point-free style, then I think you'll be letting yourself in for a lot of hassle.

> Webpack... What does this even mean?

I don't know Python too well, but I assume this is about the ability of Webpack to overload import semantics with non-code dependencies (e.g. importing stylesheets, icons, bits of JSON). Presumably Brython does not support this.

You seem quite bullish about the strengths of this project. Exactly what problems do you feel it solves? Assuming that we already have tooling like Webpack and are able to write in either ES2020 or TypeScript, what do you think we gain from writing our UI code in Python?

>Compression is not magic and minifying has real world performance gains in JS projects at least - I don't see how Python would be different here.

How much are the gains with minifying (factoring out compression) anyways? I'm sure they're somewhat faster, but enough to justify the step/obfuscation (assuming obfuscation isn't a goal)

Lambdas are an awful limitation of Python. I find myself running into "no statements in lambdas" more often than not. I hate Python lambdas.

The rest of your points are fine though.

If a function is so long it requires multiple statements, is it really so bad to give it a name and a separate line of code from its use? Personally I'd find that clearer, even if the language didn't enforce it.

Edit: Just in case anyone isn't aware, in Python, nested named functions have precisely the same capture rules as lambdas, so it's never a problem to replace a Python lambda with a normal function (except personal preference about code style). This is particularly in contrast to JavaScript where arrow functions are so popular partly because of their different relationship with `this` to other functions. And normal nested functions defined with `def foo():` have a benefit: they have their name attached to the object, so a traceback involving it will be clearer, which isn't true for `foo = lambda ...` or `bar(fn=lambda...)`.

In practice? Yeah. It sucks. In Javascript, I'd simply add curly braces and be done with it.

Code is meant to be clear. And often times with Python lambdas, there's no reason to give the function a name. It's a callback. What would you name it? "Callback"? You're adding extra complexity for no gain.

But, whatever. It is what it is. Javascript has its own pile of limitations. I was just saying that Python isn't a flawless butterfly.

Yes just call it "callback" if necessary. In the situations I'm imagining, that would still make the code clearer than using one statement to cram in both the definition of the multi-statement function and the use of it in another function.

But maybe we're imagining different situations, and maybe that's the real reason we don't share the same point of view.

> It's a callback. What would you name it? "Callback"? You're adding extra complexity for no gain.

Anon callbacks are annoying for anybody who needs to debug performance. I don't see how naming functionality increases complexity either.

100% this. When I write Javascript or Scala, I do this anyway just because it’s a better way to structure code.

Nested anonymous functions that contain complex bodies and rely on scope closure of args or local variables inside the complex bodies of exterior anonymous functions needs to stop being a thing, in any language, anywhere. It’s a massive antipattern.

Same for using functional programming constructs like map or filter or reduce with complex multi-statement nested anonymous functions. “Inlining” your anonymous function when it’s not just a simple statement is simply a terrible idea across the board.

It’s like living in crazy town to see that style defended as reasonable or treated like it’s valuable for a use case, etc.

> It’s a massive antipattern.

Yes! I used to be on-the-fence about this, but then had to try and decipher code like YDKJS’s `run` [0]. Four levels of nested functions!

Python’s syntax makes this sort of thing impossible, which I now consider to be a good thing.

[0] https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async...

Because you can write bad code using a pattern does not make it an anti-pattern.

Thanks to ES6, the async/await keyword for Promises help you get rid of the callback hell that Javascript can easily be.

Python support of asynchronous code is far behind Javascript and it is the basic requirement of frontend development.

Huh? Python async has been in the lead for quite a while now. The only thing it doesn’t have is anonymous inline function syntax.

Node's design of Worker Thread, Promise and async/await makes an easier combo than Python + asyncio/trio which requires a lot of work to get it done.

But in the end, use what works for you, and if you need performance, you still have Go, Rust, and/or C++.

Functional programming constructs helps you write simple code faster, and clarify the algorithm.

It is easier to rearrange, to test and to reason about, but it is harder to read.

Once your fast-written code works, you obviously need to optimize it where it's needed. And if you map/filter/reduce is your bottleneck, just get rid of it obviously.

But I highly doubt it will be your bottleneck.

Nested anonymous function that rely on scope closure is THE way to truly encapsulate your data, example: https://pastebin.com/JrAP6yGP

IMHO, the factory pattern is a clearer/easier pattern than Javascript's classes/prototypes.

I've been writing Python professionally for a while now, and the one thing I always want to reach for are multi-line anonymous functions. However, I do appreciate how Python prevents some of the callback hell one can encounter in JavaScript codebases.

There is a difference between abusing anonymous functions, and situations where anonymous functions might be called for, where it just so happens that those functions require more than one line of code.

>If a function is so long it requires multiple statements, is it really so bad to give it a name and a separate line of code from its use? Personally I'd find that clearer, even if the language didn't enforce it.

Sometimes this is the case. But let's take for example filtering an array. Do you really want to give names for the callback that will filter? Also I find it more readable if the logic doing the filtering is right there where the filter call is, and not somewhere above.

It sort of is a pain point because you need to move the code out of wherever the lambda was into its own block elsewhere. Breaks up the flow and is awkward. I'd love to see some kind of block lambda syntax in Python. The one drawback of whitespace syntax...

"Whitespace syntax" is not the problem. It is that Guido thinks that the anonymous callback style is harder to read and therefore something to avoid most of the time. I tend to agree.

It's the problem inasmuch as the way you'd spell an anonymous block is non-obvious considering that it would have to work as an argument to a function or element of a literal and in both of those cases indentation is freeform.

Given that lambda won't accept more than one expression even on its own dedicated line, I think the discussion is moot.

I could imagine a working syntax as indentation already works properly between parens and brackets.

And I think a lot of people are starting to realize that "callback spaghetti" might not be the best structure to give your code either.

> > So now we can write web apps in one of most inappropriate languages for frontend development.

> Implying that javascript was ever appropriate.

No such implication was ever made. That 1 < 2 doesn't make 2 infinity.

The only thing with 'just gzip it' is that actually minification+gzip does seem to give slightly better results than just gzipping it. This is partly going to be because there are some things that gzip doesn't know it can remove that a minifier does - e.g. comments. Presumably this difference is exacerbated if your codebase uses long/descriptive names and many long comments. Not that this is a particular problem for Python on the web of course because minifiers do exist for it.

On Javascript, maybe so.

But Python has different character chain probabilities and will compress differently.

> Lambdas are supported, what do you mean?

Lambdas are not functions. You can't have statements in them, only expressions. So no, they don't cut it as anonymous functions.

>> Webpack does a great job of handling assets by simply importing/require them in the code. Python import system, can't support that kind of importing.

>What does this even mean?

It means that in JS you can do "require('./image.png')" and webpack will automatically handle the image for you. Python doesn't have any way to import anything that is not .py file.