ergo14

That's a lot of absolutes. And there is no defensible proof, just anecdotal evidence. I've been in a few companies from EU and US - and in my experience it is not ture. However after working for US companies I can understand why one would come to your conclusion, however the world is bigger than our bubbles.

Lit also does fine without VDOM and has good performance characteristics.

You are holding it wrong ;)

Ok, how big percentage of them implement data consistency in your company? :)

So all your microservices implement sagas or other synchronisation patterns that ensure 100% data consistency?

No one pushes for anything agressive in Poland - the only narrative is that we and baltics should be ready to defend ourselves.

Try https://channelstream.org/ - you can talk via rest calls to it - it scales up to thousands of connections on a single small machine. You have tiny JS WS/long pool clients available with reconnection logic or you can roll your own if you like.

Thing is Kobo doesn't tie you anywhere - I use it in europe - I never ever used their online store even once.

I have Kobo H2O and it works great till this day. I charge it very rarly - maybe every 2-3 months. It reads everything I like. And it was one of the first with IP68 certification.

I really love what Nicolas is doing. But it kinda feels like whole Haxe ecosystem driving force is this one guy.

In this case was multicore computation without GIL if i remember correctly.

We speed up our ML code 40 times using it.

I think stencil or Lit are more interesting. I'm not sure I'm the fan of small libs like Lit or preact - I think for scenarios where you have more than 2-3 elements you will have less bytes over the wire very quickly.

My dell e5470 will bluescreen 80% of time when connecting a screen via HDMI on windows 10. Nothing like that happens under linux. The "it just works on other platform" is a myth - they all suck in different ways.

You could probably separate those with tooling.

Then maybe look at https://lit.dev/ it might be perfect solution for you, stencil i've heard is also nice. Since its custom-elements you just add custom tags and they will self upgrade.

TP-Link is not cloud based - you can run the controller locally. https://www.tp-link.com/pl/support/download/omada-software-c... - Downloadable here.

But can it do everything sqlalchemy can do? It is not a data mapper ORM it seems.

or Lit-Element.

I don't think we've ended up with libs that share state in a dangerous way, maybe we got lucky.

Weird, we do it with Python all the time. Just don't use globals/threadlocals everywhere and you will be good.

Imagine be you build a "search users" page with many filters, you will end up inventing query builder at one point. The more dynamic data you need, you will end up reinventing those systems. The worst that can happen is when you start concatenating sql queries together.ORM/query builders save you that headache.

The trick is to always auto close transactions at the end of the request.

Same here, I'd like to dive into golang. But there is nothing as good as SQLAlchemy. Maybe with generics we will start seeing some projects that can fill the gap.

Like... Query.join(), https://docs.sqlalchemy.org/en/13/orm/tutorial.html#querying... .

Doesn't, I wanted to show how it can be wired to request.

Check out how things are wired with in this Pyramid cookie cutter.

https://github.com/Pylons/pyramid-cookiecutter-starter/blob/...

I think same approach should work well for flask - just tie the session to the request object on first access.

Side note: I think we met on IRC few years ago ;-)

We are running sqlalchemy in a giant environment - hundreds of millions of users. SQLAlchemy has been a blessing for us. Blame users that use flask-alchemy or whatever else is cool. This is exactly the same type of comment that blames ORM-s for ineffective SQL being used because people don't know how to write the queries in the first place.