Reahl – A Python-only web framework
reahl.org
reahl.org
Dash is awesome for early stage , production ready prototyping.
The state management between the browser and the dash backend is not intended to be touched by a user.
Not that it's not interesting of them to make this, but really, I had little if any temptation to try it out.
Note that it doesn't necessarily mean I think JS/CSS is _better_ suited, but in any case not worse, and I think the leap from one problem domain to another is much more significant than the leap from one language to another.
Given the immense speed of today’s computers, brute force might be enough, though.
Anvil also emphasises their dev tools, it’s quite an integrated environment, between IDE, data, and deployments.
Apparently it should be the case.
> AGPL means you have to share any code you write using this framework
I think you've found the reason?
AGPL puts no restrictions on commercial usage, as far as I am aware.
> AGPL isn't made with libraries in mind...
It works perfectly well with libraries.
I don't get it. What would be so wrong about making your source code available to everyone (including your competitors)? Remember, if your source code is AGPL and someone uses it, their source code is also AGPL and they must make their changes available to their users.
If you deliver real value to your customers, the fact that your source code is publicly available should be a plus point for your customers.
Why would they not allow AGPL? It's a perfectly valid free software licence.
It's not a webassembly framework, and it doesn't seem to go the "thin client" approach of managing DOM changes and events over a two-way protocol.
Of course, there's the "just looking to build something (serious or not) and not concerned about it becoming a profitable business" group of people - like you, perhaps - and that's great! But it generally takes a lot of enthusiasts before a library becomes accepted as mainstream and a certain amount of luck is required for that to happen.
From the few examples in the README I'd say that it makes development more complex than using the usual server side rendering approaches. I'm also not sure Python is the best language for this sort of things. Better than Java but usually Ruby is better at DSLs.
Why not?
I would say it is the other way around. For any web application project of decent size there is almost always a transpilation step that converts whatever programming language your source code is in, into JavaScript (usually ES5). We also had very successful and widely used projects like GWT for years (GWT was first released in 2006!!!).
I can make a sophisticated python web app with 20 packages. Or in JavaScript I'll need a few hundred that have massive vulnerabilities and conflicts. Hell npm reported the most modern packages I was installing had over 200 vulnerabilities. JavaScript pretty much guarantees shit code. I'll be downvoted to hell, but whatever. Js sucks.
Even javascript itself isn't "bad". There are ugly parts but anything written in the modern spec is basically semantically the same as any other language like python.
The problem is that people writing packages on the backend are bootcamp grads, frontend devs, and any number of other people who don't take the backend as seriously as someone who has been devoted to it using a non-javascript language.
I think the other issue is the javascript community wants to reinvent itself every couple months, instead of having one project that becomes defacto for x function over many years.
Even react which from limited experience is pretty cool. But apparently there must be dozens possibly hundreds of true senior devs in the US. Most everyone else fucks it up.
And I agree there is a shallow depth in the js world. Everyone wants the new shiny toy instead of using an evolving toolkit. JS is the embodiment of ADD.
It is entirely possible that Javascript itself is an OK language, but it is too late now. The community has already decided that packages should be tiny, that changing prototype of "array" object is an acceptable thing to do, that failing fast is bad and the best reaction to errors is to mess up the page layout in the unexpected way, and so on.
Maybe one day, Javascript will re-invent itself and get reliable software engineering practices. But I highly doubt that -- there are countless people who know the laguage already, and they are not going to be changing their opinions overnight.
Uhh, no? I code in JS every day and do nothing of the sort, and I would object if I saw it.
> failing fast is bad and the best reaction to errors is to mess up the page layout in the unexpected way
I don't even know what you mean by this, but the fact that you're conflating JS with "the page" suggests to me that you're not that familiar with server-side JS (which has no "page") and the enormous amount of code that is written to be compatible with it.
If you use Babel you already have that, and just don't know about it. Most "upcoming features" shims do just that.
I don't think so, you can always just use the language in your own style and cherry-pick any tools that align with it.
Like e.g. the Play framework ignored the main standards and idioms of Java development in its day.
Or how every game studio just uses its own version of C++ and forbids tons of features.
"I had a bad experience (being unexperienced and only delving into that ecosystem a couple days ago) so it's bad"
How about you? Do you consider yourself a senior after a couple of years of js?
If people want to go wild with fad frameworks and libs every year or so, that's their thing. But you can have absolutely stable systems with very few dependencies if you wish so.
If I was forced to on a couple projects I've seen I'd ask for 10k raise.
Ok. Now that you got this off your chest and you want to build an application that can run inside a browser (i.e. a platform available to billions)...what do you do?
Wt: https://en.wikipedia.org/wiki/Wt_(web_toolkit)
JWt: https://en.m.wikipedia.org/wiki/JWt_(Java_web_toolkit)
GWT: https://en.wikipedia.org/wiki/Google_Web_Toolkit
Now we have Babel, ES YYYY, and faster browser release cycles.
Maybe not.
Would anyone use this for “line of business” applications? Internal tools? The signed-in experience on an enterprisey product?
Most definitely.
Guess which one 90% of software falls into.
I work at a tech company, we sell to consumers, we’d never use this for customer facing stuff, but being able to rapidly build web apps that show tabular data and editing controls with various integrations with our services for internal customers and partners is critical. If we built that as fancy React apps all the time we’d never get anywhere.
You'd be surprised. Many highly successful websites and services use non-mainstream projects.
Besides that trite observation could have been said for any project (even the most successful ones like Rails) when they first started.
In my experience all these frameworks end up lacking at some point and becoming leaky abstractions sooner than later. I wish they would work because all the front end technologies require lots of training and skill in order to produce a production ready UI.
Ultimately, for me, it comes down to what makes sometimes complicated declarative code easier to reason about, read and understand - it's a simple as that.
Some things are just _easier_ to write when you've got the power of a Turing-complete language with a decent standard library behind you; if for example you want to dump out a sorted list and then be able to easily update it later, or print a list of links alongside a hash of the contents of their targets.
I guess if you're building a simple website, anything like this tool could be overkill and you'd risk spending more time setting things up - and maintaining it in the future - than you'd be likely to save by using the tool in the first place. But for more complicated output having more tools to use lets you be arguably more declarative; you just change the input data to generate the desired output. You describe and allow automation of the _transition_ from input data to the desired end point.
I could definitely see how libraries like this would be tremendously useful for generating HTML. As it happens for our AWS infrastructure generation we enforce the use of Troposphere everywhere, because in that case the cost of setting up and maintaining it is essentially just copy-pasting an existing Makefile.
My hunch is that you strove for making the First Comment considering that the point of this project is exactly what you said it isn't.
https://www.reahl.org/layout, for instance, talks about how styling works.
Taking this further, here's a comment from one of the maintainers on the relevant Google Group:
> Hello.
> We want casual users of Reahl to be shielded from complexities such as client side scripting and CSS.
> HOWEVER, if you are prepared to move to the next level of learning you can build your own Widgets. When you build your own Widget you can do anything you like - using techniques tutorial.pagerbootstraptutorial.pagerbootstrap that you would have used with a traditional framework.
Hopefully this answers your question.
I really don't think so. It might not be as mature as one might want in production, but from what I can tell, it certainly fulfills the title's assertion in enough useful contexts to be accurate.
But it may be close, like you can spend 90% of your development time on Python, and write JS components in the remaining 10%.
About half-way down is "Write code for a JavaScript widget"
You seem pretty steadfast in your commitment that this post misrepresents its content. I believe you should give it a deeper review and reevaluate your understanding.
What's wrong with simply "Reahl 4.0: Build web apps in Python".
It's clear and truthful.