Implying that javascript was ever appropriate.
> White space significant, good luck minifying it.
Just gzip it. Minifying is highly overrated to begin with.
> No anonymous functions, yes you need to have name for that callback, even though it's simply disabling a button.
Lambdas are supported, what do you mean?
> 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?
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?
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)
The rest of your points are fine though.
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...)`.
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.
But maybe we're imagining different situations, and maybe that's the real reason we don't share the same point of view.
Anon callbacks are annoying for anybody who needs to debug performance. I don't see how naming functionality increases complexity either.
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.
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...
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.
But in the end, use what works for you, and if you need performance, you still have Go, Rust, and/or C++.
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.
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.
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.
I could imagine a working syntax as indentation already works properly between parens and brackets.
> Implying that javascript was ever appropriate.
No such implication was ever made. That 1 < 2 doesn't make 2 infinity.
But Python has different character chain probabilities and will compress differently.
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.
There is no reason to shit on someone's work just because you think it was a bad idea. It's already done, and it can coexist in the universe with you.
That isn't the goal of this project though. From https://brython.info/static_doc/en/intro.html:
> Brython's goal is to replace Javascript with Python, as the scripting language for web browsers.
Given that stated aim, I feel like the original criticisms have their place here.
If zaro is wrong (and people pounce on him for being technically wrong), Brython will indirectly be vindicated. If he's right, it's the perfect opportunity for break down just how right he is; e.x, if future client-side languages will be shaped by their suitability for minification or if content compression obviates this.
I think even for new projects, this is good. Nobody arrogates themselves to the belief their project will be as influential as the most well known projects started just for fun (n.b "Just For Fun, Torvalds (2002)") and no critical commenter should pretend they are with replies that hide hostility behind concern for our future... but by the time news of it's development has reached us here, the sliver of chance that Brython will join their ranks is no longer microscopic. I'm reminded of early CoffeeScript (and even Javascript itself), which could have avoided numerous pitfalls with early constructive(!) criticism from cantankerous commentators.
No matter what, the armchair quarterbacks will be taken down a notch if they're wrong and are worth your time otherwise. Those early complaints help decide if your future is filled with a junkyard of half-baked software or manages to harness our collective wisdom (with a healthy dose of individual discretion) to refine itself into something elegant and powerful.
It's not that hard to see Brython doing just that either; you don't need to be Nostradamus to foretell a prophecy of an easy-to-use, "just works" implementation of Python3 in the browser profoundly altering the current landscape, shaping our future toolbox and even what software is thought possible.
why should JS have all the fun!?
For example: "I have code that already exists in Python that I want to reuse in a browser" or "I am fluent and very productive in Python and I just need to get shit done".
I don't think anyone expects this to replace javascripts for normal public-facing web development. Do they?
While I cant vouche for this implementation if you want to minify Python you compile it to bytecode and run that. Works wonders for embeded deployments of Python.
The following argument isn't necessary for folks who do want Python in frontend but still, not all of your points hold true, Python can handle multiple commands in a single line and it does have anonymous functions: lambda.
From the article:
> Brython is designed to replace Javascript as the scripting language for the Web.
So it does sound like they are asking people to use Brython instead of JavaScript.
> it does have anonymous functions: lambda.
But they're not fully featured functions, though, being restricted to a single expression.
Sometimes as a programmer you need to learn new tools for new domains, and that's not necessarily a bad thing.
Too often I've seen companies stuck with an old framework just because their developers are used to it. That's how you get a microservice architecture in Java where each containers takes 300MB of space, and requires 1GB of memory.
async for event in element.on("click"):
console.log("click")The newline is mandatory, but the indents can be truncated easily using pyminifier - https://liftoff.github.io/pyminifier/
Naturally, if I was making a decision for a company I worked at, I would do my due diligence and likely end up using JS for any of a number of reasons that don't have to do with how unpleasant and unproductive working in the language is. But for personal projects, I'd happily use something like this, short of discovering a show-stopping problem with it.
The thread OP comment just seems like classic defensiveness about JS; a project like this is never going to be literally perfect for corporate production use on day one or but it doesn't need to be to be useful. Even on the off chance that it were to grow into something widely useful, at that point you'd see a lot of powerful actors polishing off the rough edges. This is exactly what happened to Javascript: the only reason it's defensible at all is because of the millions of dollars poured into it and its ecosystem by companies like Google, Mozilla, etc
That said, in order to support `eval` and friends, you still need a full-fat compiler in the browser. So the best route is probably to use a full-service Python->JS compiler, but compile most of the code ahead of time. That's where we're heading with Anvil (we use https://skulpt.org for the client side, but it's the same principle).
My colleague wrote up a pretty wide-ranging comparison of browser-based Python interpreters. It describes how (and why) Brython, Batavia, Skulpt, Transcrypt, and Pyodide differ, and the tradeoffs they're chasing:
This is the only part left that uses it, to create the constructor: https://github.com/python/cpython/blob/master/Lib/collection...
Even there it's not strictly necessary. You could accomplish the same thing with a variadic function that does its own argument parsing, it'd just be slower and not play as well with reflection. So you could port it to a Python implementation without eval().
The question being avoided is: how does the ergonomics of DOM and network access fit on both?
From the examples, it's mostly similar.
Would it be hard to define an alternate representation of Python code that uses curly braces instead of white space to use over the wire for delivery of front-end Python (with curly braces that occur in the original Python code escaped)?
This code, for example:
def func(foo, bar):
if foo < bar:
foo += bar
return foo * 3
def func(foo, bar):{if foo < bar:{foo += bar}return foo * 3}
Going back from curly representation to significant white space is easy and fast, although you could probably build your tokenizer so that it never even has to bother. That could make the client side handling of this essentially free.
Brython supports precompilation to JS, which is obviously minifiable.
> on top of that you are running Python interpreter in the JS VM.
No, you aren't. Brython is not a Python interpreter, but a compiler to JS. There are optimization issues from the need to maintain Python semantics interfering with optimizing the JS, but that's not the same as running a Python interpreter.
Surely it sends the bytecode to be run by the interpreter...
I don't mean to put shit on any body's work. I am just noting several obvious flaws to the idea. Now it might sound like putting shit, I don't know, but I am not native speaker so sometimes I guess I am using the wrong tone/working.
The real question for me is why it's such a big deal? In the end its simply an opinion.
White space significant, good luck minifying it.
No anonymous functions, yes you need to have name for that callback, even though it's simply disabling a button.
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.
And of course there is the performance. Python is generally slower than JS, and then on top of that you are running Python interpreter in the JS VM.