7 ms·

So now we can write web apps in one of most inappropriate languages for frontend development. White space significant, good luck minifying it. No anonymous fu

by zaro 6y ago

So now we can write web apps in one of most inappropriate languages for frontend development. 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.

skocznymroczny 6y ago
Couldn't you just sent the bytecode .pyc instead to fix the no minification issue?
- meredydd 6y ago
  This is exactly what BeeWare's Batavia does: compile to bytecode server-side, then run a remarkably small interpreter in the browser. This is a substantial win: parsing is a CPU hog, and Brython's architecture does it every time the page loads. 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 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: https://anvil.works/blog/python-in-the-browser-talk https://anvil.works/blog/python-in-the-browser-talk
  - StavrosK 6y ago
    In twenty years of professional Python development, I've never used eval once. I'm not saying nobody ever needs it, but it's a niche feature that the vast majority of programs can do without, and is probably not worth the tradeoff.
    - jononor 6y ago
      You probably have used a Python REPL though? Either on commandline or in iPython shell or similar. This relies on eval type functionality somewhere in the chain.
    - _ZeD_ 6y ago
      have you ever used namedtuple? then you have: https://bugs.python.org/issue3974 https://bugs.python.org/issue3974
      - duckerude 6y ago
        namedtuple could be implemented without exec/eval, and nowadays, it almost is. This is the only part left that uses it, to create the constructor: https://github.com/python/cpython/blob/master/Lib/collections/__init__.py#L430 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().
    - danijar 6y ago
      It's necessary if you want to offer an interactive Python shell in the browser, e.g. for websites that teach programming or otherwise use programming as a means of user interaction.
      - airstrike 6y ago
        Which is like 0.0001% of the web
- weego 6y ago
  This is just a python interpreter. pyc is useless here
  - pletnes 6y ago
    The interpreter interprets bytecode, i.e .pyc
- cellularmitosis 6y ago
  Whitespace isn't the important part of minification. Content-encoding: gzip can handle that.
tcbasche 6y ago
> White space significant, good luck minifying it Surely it sends the bytecode to be run by the interpreter...
- zaro 6y ago
  Did take a look at least one example? It's python code embedded in script tag. I don't see any byte code.
KaiserPro 6y ago
> So now we can write web apps in one of most inappropriate languages for frontend development. why should JS have all the fun!?
andybak 6y ago
I'm not sure if any of the points you raise would be a deal breaker when set against the potential advantages for some people. 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?
blumomo 6y ago
Noone asks you to use Brython. People familiar with Python might prefer writing their frontend code in Python just because they are already familiar with it. 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.
- dghf 6y ago
  > Noone asks you to use Brython. 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.
  - blumomo 6y ago
    I would differentiate between marketing speak (designed to replace Javascript) and the practical implications of Brython (designed for folks who want to use Python in frontend)
    - jbreckmckye 6y ago
      If I were a JS developer who only wanted to write JS, but I needed to do a database query, should I look for a database that lets me write queries in JavaScript (or a language basically interchangeable with JS)? Or should I just learn SQL? Sometimes as a programmer you need to learn new tools for new domains, and that's not necessarily a bad thing.
      - linkdd 6y ago
        This. 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.
      - 6y ago
pjmlp 6y ago
We already could do that back in 2000, provided the user had IE installed, via ActiveX. I have provided the links in another comment.
thefounder 6y ago
Believe it or not most server-side developers find javascript ecosystem an awful experience so I doubt they care about Webpack or any of the JS "innovations". The speed is not really an issue given that most of the client apps just call DOM/Web API functions.
- wutbrodo 6y ago
  Yea, there always seems to be a disconnect in these conversations between people who aren't yet used to Javascript's grotesqueness and those who are desensitized to it. Javascript was so horrible for so long, and remained horrible every time I tried it because "seriously, it's good now", that there's a fairly significant threshold to get me interested in using it when any other alternative is available. 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
kabacha 6y ago
> So now we can write web apps in one of most inappropriate languages for frontend development. 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?
- sillysaurusx 6y ago
  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.
  - quietbritishjim 6y ago
    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...)`.
    - sillysaurusx 6y ago
      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.
devxpy 6y ago
A white space is just a newline and an indent. The newline is mandatory, but the indents can be truncated easily using pyminifier - https://liftoff.github.io/pyminifier/ https://liftoff.github.io/pyminifier/
beowulfey 6y ago
This is some pretty intense negativity. What's wrong with doing something just for the hell of it? People will choose naturally whichever may be the most efficient methods. 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.
- 727564797069706 6y ago
  Your attitude makes the world a better, more open place for everyone. Thank you for your comment!
- shermheadryder 6y ago
  > What's wrong with doing something just for the hell of it? That isn't the goal of this project though. From https://brython.info/static_doc/en/intro.html 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.
- hevelvarik 6y ago
  He could have presented less snarky, but the comment is appropriate and helpful. The comments are the low effort way to get a feel for the technical viability of the tech featured in the main post.
- ZephyrP 6y ago
  > 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. 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.
giancarlostoro 6y ago
> White space significant, good luck minifying it. 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.
rburhum 6y ago
You know, this idea that removing whitespace is the best way to reduce code size for delivery can be debunked by any student that takes a compiler class. That technique + gzip is a shortcut that we have taken as a defacto “right way” of delivering web code (of course taking out the whole conversation of WebAssembly). Perhaps something good can come up out of this - just like people pissed all over the idea of js on the server when node.js came out, perhaps this has the potential of doing the reverse on the client side. Stay open minded.
mesaframe 6y ago
Well, you are just nit picking arguments to attack Python. If compared independently anyone would choose Python over JavaScript.
- deleted 6y ago
  [deleted]
- azangru 6y ago
  I would choose typescript over either; but if not given such an option, would choose javascript over python.
  - zaro 6y ago
    Same here.
- fiddlerwoaroof 6y ago
  I guess I'm not anyone, then: given a choice, I'd pick JavaScript over most non-Lisps
- hombre_fatal 6y ago
  Node shows that this is false. You live in a 2002 bubble if you still think anyone would choose any language over Javascript any time. Python to me only ranks above PHP and I wouldn't use it at all if it weren't for its math/ML subcommunities.
MattGaiser 6y ago
We routinely dump 3Mb images on every webpage. I think we can spare a bit of space for spaces.
marcosdumay 6y ago
That's a great list of non-issues. The question being avoided is: how does the ergonomics of DOM and network access fit on both? From the examples, it's mostly similar.
hxzhao 6y ago
first of all, I don't think "most inappropriate languages for frontend development" is a thing, it is just a new way to do web dev that is different to what you used to be doing with. If you don't think it is an approach that you prefer/can accept, you can just move on continue with whatever you like. You should learn from the people who built Brython, they don't like the way how the current web is being built - hence they continue doing what they believe its right, BUT wihtout putting shit on other's people's work.
- zaro 6y ago
  There are people who think images and JS are far too much for the Web (you can often read comments like that on HN) and want pure text only Web. Should we learn from them too? 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.
tzs 6y ago
> White space significant, good luck minifying it 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 might become on the wire: def func(foo, bar):{if foo < bar:{foo += bar}return foo * 3} That could then be subject to the usual minimization approaches. 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.
- dfox 6y ago
  Both CPython's parser and Python language grammar works in terms of indents/dedents being represented by brace-like tokens, so this is trivially possible transformation.
dragonwriter 6y ago
> White space significant, good luck minifying it. 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.

by zaro 6y ago

skocznymroczny 6y ago

Couldn't you just sent the bytecode .pyc instead to fix the no minification issue?

meredydd 6y ago
This is exactly what BeeWare's Batavia does: compile to bytecode server-side, then run a remarkably small interpreter in the browser. This is a substantial win: parsing is a CPU hog, and Brython's architecture does it every time the page loads. 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 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: https://anvil.works/blog/python-in-the-browser-talk https://anvil.works/blog/python-in-the-browser-talk
- StavrosK 6y ago
  In twenty years of professional Python development, I've never used eval once. I'm not saying nobody ever needs it, but it's a niche feature that the vast majority of programs can do without, and is probably not worth the tradeoff.
  - jononor 6y ago
    You probably have used a Python REPL though? Either on commandline or in iPython shell or similar. This relies on eval type functionality somewhere in the chain.
  - _ZeD_ 6y ago
    have you ever used namedtuple? then you have: https://bugs.python.org/issue3974 https://bugs.python.org/issue3974
    - duckerude 6y ago
      namedtuple could be implemented without exec/eval, and nowadays, it almost is. This is the only part left that uses it, to create the constructor: https://github.com/python/cpython/blob/master/Lib/collections/__init__.py#L430 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().
  - danijar 6y ago
    It's necessary if you want to offer an interactive Python shell in the browser, e.g. for websites that teach programming or otherwise use programming as a means of user interaction.
    - airstrike 6y ago
      Which is like 0.0001% of the web
weego 6y ago
This is just a python interpreter. pyc is useless here
- pletnes 6y ago
  The interpreter interprets bytecode, i.e .pyc
cellularmitosis 6y ago
Whitespace isn't the important part of minification. Content-encoding: gzip can handle that.

tcbasche 6y ago

> White space significant, good luck minifying it Surely it sends the bytecode to be run by the interpreter...

zaro 6y ago
Did take a look at least one example? It's python code embedded in script tag. I don't see any byte code.

KaiserPro 6y ago

> So now we can write web apps in one of most inappropriate languages for frontend development. why should JS have all the fun!?

andybak 6y ago

I'm not sure if any of the points you raise would be a deal breaker when set against the potential advantages for some people. 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?

blumomo 6y ago

Noone asks you to use Brython. People familiar with Python might prefer writing their frontend code in Python just because they are already familiar with it. 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.

dghf 6y ago
> Noone asks you to use Brython. 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.
- blumomo 6y ago
  I would differentiate between marketing speak (designed to replace Javascript) and the practical implications of Brython (designed for folks who want to use Python in frontend)
  - jbreckmckye 6y ago
    If I were a JS developer who only wanted to write JS, but I needed to do a database query, should I look for a database that lets me write queries in JavaScript (or a language basically interchangeable with JS)? Or should I just learn SQL? Sometimes as a programmer you need to learn new tools for new domains, and that's not necessarily a bad thing.
    - linkdd 6y ago
      This. 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.
    - 6y ago

pjmlp 6y ago

We already could do that back in 2000, provided the user had IE installed, via ActiveX. I have provided the links in another comment.

thefounder 6y ago

Believe it or not most server-side developers find javascript ecosystem an awful experience so I doubt they care about Webpack or any of the JS "innovations". The speed is not really an issue given that most of the client apps just call DOM/Web API functions.

wutbrodo 6y ago
Yea, there always seems to be a disconnect in these conversations between people who aren't yet used to Javascript's grotesqueness and those who are desensitized to it. Javascript was so horrible for so long, and remained horrible every time I tried it because "seriously, it's good now", that there's a fairly significant threshold to get me interested in using it when any other alternative is available. 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

kabacha 6y ago

> So now we can write web apps in one of most inappropriate languages for frontend development. 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?

sillysaurusx 6y ago
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.
- quietbritishjim 6y ago
  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...)`.
  - sillysaurusx 6y ago
    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.

devxpy 6y ago

A white space is just a newline and an indent. The newline is mandatory, but the indents can be truncated easily using pyminifier - https://liftoff.github.io/pyminifier/ https://liftoff.github.io/pyminifier/

beowulfey 6y ago

This is some pretty intense negativity. What's wrong with doing something just for the hell of it? People will choose naturally whichever may be the most efficient methods. 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.

727564797069706 6y ago
Your attitude makes the world a better, more open place for everyone. Thank you for your comment!
shermheadryder 6y ago
> What's wrong with doing something just for the hell of it? That isn't the goal of this project though. From https://brython.info/static_doc/en/intro.html 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.
hevelvarik 6y ago
He could have presented less snarky, but the comment is appropriate and helpful. The comments are the low effort way to get a feel for the technical viability of the tech featured in the main post.
ZephyrP 6y ago
> 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. 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.

giancarlostoro 6y ago

> White space significant, good luck minifying it. 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.

rburhum 6y ago

You know, this idea that removing whitespace is the best way to reduce code size for delivery can be debunked by any student that takes a compiler class. That technique + gzip is a shortcut that we have taken as a defacto “right way” of delivering web code (of course taking out the whole conversation of WebAssembly). Perhaps something good can come up out of this - just like people pissed all over the idea of js on the server when node.js came out, perhaps this has the potential of doing the reverse on the client side. Stay open minded.

mesaframe 6y ago

Well, you are just nit picking arguments to attack Python. If compared independently anyone would choose Python over JavaScript.

deleted 6y ago
[deleted]
azangru 6y ago
I would choose typescript over either; but if not given such an option, would choose javascript over python.
- zaro 6y ago
  Same here.
fiddlerwoaroof 6y ago
I guess I'm not anyone, then: given a choice, I'd pick JavaScript over most non-Lisps
hombre_fatal 6y ago
Node shows that this is false. You live in a 2002 bubble if you still think anyone would choose any language over Javascript any time. Python to me only ranks above PHP and I wouldn't use it at all if it weren't for its math/ML subcommunities.

MattGaiser 6y ago

We routinely dump 3Mb images on every webpage. I think we can spare a bit of space for spaces.

marcosdumay 6y ago

That's a great list of non-issues. The question being avoided is: how does the ergonomics of DOM and network access fit on both? From the examples, it's mostly similar.

hxzhao 6y ago

first of all, I don't think "most inappropriate languages for frontend development" is a thing, it is just a new way to do web dev that is different to what you used to be doing with. If you don't think it is an approach that you prefer/can accept, you can just move on continue with whatever you like. You should learn from the people who built Brython, they don't like the way how the current web is being built - hence they continue doing what they believe its right, BUT wihtout putting shit on other's people's work.

zaro 6y ago
There are people who think images and JS are far too much for the Web (you can often read comments like that on HN) and want pure text only Web. Should we learn from them too? 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.

tzs 6y ago

> White space significant, good luck minifying it 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 might become on the wire: def func(foo, bar):{if foo < bar:{foo += bar}return foo * 3} That could then be subject to the usual minimization approaches. 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.

dfox 6y ago
Both CPython's parser and Python language grammar works in terms of indents/dedents being represented by brace-like tokens, so this is trivially possible transformation.

dragonwriter 6y ago

> White space significant, good luck minifying it. 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.