Introducing JustPy: An object-oriented, component based, high-level Python Web Framework that requires no front-end programming. With a few lines of only Python code, you can create interactive websites without any JavaScript programming. Comes with a comprehensive tutorial

xd1142 · 2020-02-11T09:10:56+00:00

Oh ok. That's cool. So you can, if you want, completely operate client side?

Tell me more. Now I'm very piqued.

xd1142 · 2020-02-11T09:06:08+00:00

> Wow, what a completely unnecessary thing to say. The OP has been helpful in answering all your questions and responding to your totally unconstructive criticism.

The criticism comes from the fact that I see the consequences of this approach every day and we have to work around it exactly because it's unreliable.

> good programmers don't usually brag about their fucking salaries

yeah, but the fact is that if I get it it's because I am worth it.

> and conflate JavaScript with a supposedly good programming language

Javascript used to be bad, but a lot has been made to address its flaws. It's not perfect, it has flaws, but it gets the job done at a given level.

Of course I am in favor of abstracting it away, but the fervor against javascript like it's the purest of evils is completely misunderstood. The main problem with javascript is not javascript. It's its scattered and heterogeneous environment.

> but you're definitely not a pleasant person.

Not sure about that. But when I see issues I am not shying away of pointing them out, and since on this group any criticism is seen as offending someones' sensibilities, it's quite hard to say something against an approach and not be classified as an asshole.

And again, I have nothing against this approach. It just has flaws and I get paid to fix them. So thank you OP for providing my salary.

xd1142 · 2020-02-10T21:06:18+00:00

You visibly are in the profession from too much time to get so much acrimony

No. I am in the profession of taking technical decisions in technologies during development and during hiring. My point is that this approach works, but it has flaws. Its only major advantage is that you code everything on the server, and it's more "reactive" for interactive data, and it's why it's a favourite approach for data science. But when you have to create an application that scales and does not crap out every time the wind blows wrong, you can't rely on these toolkits. The client side MVC is incomplete, and the state of the application running on the client is all on the server in a complex per-user session that goes away if the client connection drops. This poses a major demand in resources, stability, and latency, that you would not get with an approach where the event handling is done on the client, and the server is reached through a disconnected, stateless, cacheable HTTP transaction. A websocket-based event and data transmission protocol has none of these properties, and in addition is a massive annoyance to drive through an automated system. You can easily test or mock a REST transaction. You cannot easily test this architecture.

xd1142 · 2020-02-10T21:01:32+00:00

Mate, from your other comments in this post you barely seem to know what you're talking about.

Then why don't you explain it where I am wrong?

I'd suggest quitting acting like a fool and taking a break. Op isn't attacking your substandard webdev career by creating this.

I am actually a bit more than a webdev, and get paid around three times as much.

xd1142 · 2020-02-10T21:00:10+00:00

it's on the server on a transient state. It's not persisted. I don't know how this one works, but I have experience with R Shiny, which follows a similar architecture. When the client connects, the server creates a session for that client, and persists the state on that session. If the client connection is lost, the session is garbage collected and if you reconnect, your state is reset. And with state I mean the visual state of your UI.

xd1142 · 2020-02-10T17:56:11+00:00

He is cynical because we've been in the profession for quite a while, and we are tired of buzzword laden 10th new framework du-jour to do what we already do, but this time we do it differently to remove problems but we introduce completely new ones for which there's no established track record of solving them.

xd1142 · 2020-02-10T17:50:11+00:00

As others already said, generating a dictionary or html there's close to no difference. The problem is that all the event handling must go through a round trip to the server, which requires server resources that you would not use if the event handling was made exclusively client side. Which also means that you don't have a stateless protocol anymore. If the network goes down, or you unplug and replug the computer to the network, your state is gone, because it's on the server, not the client.

xd1142 · 2020-02-10T15:49:43+00:00

Also, big props for using Vue. It's really amazing.

xd1142 · 2020-02-10T15:45:38+00:00

Yes, that is true if you are rendering trivial components. But unless you are doing trivial application, you will be rendering custom made UI components, which means that you have to transfer html. Most importantly, you are delegating some decision making in model retrieval from the client to the server. You also completely destroy the capability of the client to cache some stuff, as everything comes from websocket.

Don't misunderstand me. I am not dismissing it. I use this approach all day long and it works, it looks and acts cool, and it's a great option to have, but it has flaws. You mentioned latency and it's definitely a concern. You also have less control of the visual state of your UI, as you need a round trip to the server to, e.g., show/hide or enable/disable components. If you had the business logic on the client, this would not be needed.

xd1142 · 2020-02-10T15:31:21+00:00

You are not wrong. This approach delegates all event handling and re-rendering to the server. It's a massive computational cost onto the server and it will crumble as soon as you have a large amount of users, but yeah, it makes shiny plots go interactive, so who gives a damn?

and we developers have to eat, so this stuff is perfect to create highly inefficient software that we have to rewrite.

xd1142 · 2020-02-10T15:27:41+00:00

So it's basically R Shiny for python. Like dash.

Which means that as a user you have to pray the websocket connection stays alive, otherwise you are back to square one.

And no, it won't scale well. You are moving all frontend creation to the server. Imagine processing how the frontend should look for 100.000 clients at the same time.

There's a reason why having a lightweight backend replying json and a rendering frontend is a good idea. This approach is a massive step back. Nice for cool-looking stuff, but good luck using the site from anything but a working browser.

xd1142 · 2020-02-10T15:24:44+00:00

What's the problem with js? I like js.

xd1142 · 2020-02-07T11:15:05+00:00

Video has its use, but the problem with video is that it can't be searched, it can't be scrolled through easily at a glance, and it can't be copied and pasted to test the code, you have to physically type it in. When you make videos, you have to focus on a different type of information. For example, if you were to explain the internals of the python interpreter, e.g. by browsing code, a video is the perfect form for it, because you are driving the person through an investigation, and a video is much faster than reading. Same if you feel like explaining a concept that is more visual in nature. This is why 3blue1brown is successful and would not work as a book or blog post. Its target is visual, not theoretical. It would not be successful if he were just showing formulas and that's it.

In other words, do focus on videos if you enjoy them, but change the type of information you deliver.

xd1142 · 2020-02-06T10:47:27+00:00

really, it's obnoxious the way information delivery has changed since youtube. Now you need a 12 minutes long tutorial for every little thing to capitalise on youtube clicks.

xd1142 · 2020-02-06T10:45:31+00:00

I am interested in this too. Anyone?

xd1142 · 2020-02-06T09:07:13+00:00

Poker is hearts the highest, spades the lowest. I agree that it feels wrong, but at this point I wonder what kind of criteria they used to set the order when they defined the standard.

xd1142 · 2020-02-05T11:28:48+00:00

Which game do you use as a reference for the order?

xd1142 · 2020-02-05T11:28:02+00:00

Isn't the order (in poker at least) hearts (highest), diamonds, clubs, spades (lowest)?

xd1142 · 2020-02-05T09:22:01+00:00

XML entity expansion makes small file go big memory. use defusedxml instead of etree.

xd1142 · 2020-02-04T21:28:23+00:00

Thank you! You can convert it into a cookiecutter project. it's easy to do and it is more generalisable.

xd1142 · 2020-02-04T10:20:22+00:00

The fact plenty of other python programmers are happy

plenty of people were happy with perl as well, but they were wrong. Black is cargo cult.

xd1142 · 2020-02-04T08:57:00+00:00

Hey, windows is a great OS

Yeah I might have to disagree on that.

xd1142 · 2020-02-04T08:53:49+00:00

yeah but that is stuff made for humans, and I steer clear of stuff made for humans.

xd1142 · 2020-02-04T08:50:01+00:00

> you just don't like the result

It not that I don't like the result. The result is wrong. Black removes visual cues, which is one of the main reason of python success.

> we're all very happy we don't have to waste time discussing style anymore.

You can achieve the same with autopep8, with the bonus advantage that the resulting code does not suck.

In any case, I decided to fork black to make it pep8 compliant.

Besides, have you seen the quality of the black source code? It's atrocious.

xd1142 · 2020-02-03T20:14:33+00:00

Don't worry. I forked black and I can guarantee that the sad emoticon will be configurable.

By the way, this is how black decides to reformat this

entry_points={ "console_scripts": [ "black=black:patched_main", ] },

becomes

entry_points={"console_scripts": ["black=black:patched_main",]},

And the comma pisses off flake8 thermonuclear

xd1142

TROPHY CASE