Reahl – A Python-only web framework(reahl.org)
reahl.org
Reahl – A Python-only web framework
https://www.reahl.org/
107 comments
It seems conceptually similar to Google Web Toolkit. So probably it is also a nightmare to debug.
[deleted]
Needing an ajax request to paginate a table seems like a big step backwards from modern web applications.
Am I missing something? Pagination would surely require a request, unless you’re loading the full data set into the client up front, which would be a bad idea in many use cases?
In this case the request is always needed since the request returns html, not the actual data. In most frameworks (or even custom solutions) you can choose to either load the data up-front or fetch each page on-demand.
You took a declarative language (HTML) and mad it imperative (Python). Why is that a good thing?
I've been thinking about this sort of thing a lot recently in terms of our heavy use of Troposphere[1] which is a Python abstraction over AWS CloudFormation and how much better that abstraction is than just writing HTML (in the case of this library) or JSON/YAML (in the case of CloudFormation) directly.
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.
[1] https://github.com/cloudtools/troposphere/
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.
[1] https://github.com/cloudtools/troposphere/
If you like troposphere, you'll love stacker:
https://github.com/cloudtools/stacker
https://github.com/cloudtools/stacker
I guess it is mostly the subjective comfortableness of python (and the capacity of throwing prototypes for a team who has only python skills).
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.
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.
What are big differences compared to Django and Flask?
How is this different from Vaadin (other than the language, of course)?
https://vaadin.com/
https://vaadin.com/
That's a pretty big difference though.
Would also like to know major differences to Anvil?
Anvil is hosted, or an on-prem server, whereas it looks like this can be run anywhere. I’d guess that’s the major difference.
Anvil also emphasises their dev tools, it’s quite an integrated environment, between IDE, data, and deployments.
Anvil also emphasises their dev tools, it’s quite an integrated environment, between IDE, data, and deployments.
Haven't heard of this before. Seems cool!
Very cool project. Are there any major apps that use Reahl? I can't find any.
What's wrong with building them in Javascript :)
Does APL here mean you can only use it ti build APL-licensed server code?
Apparently it should be the case.
Apparently it should be the case.
AGPL means you have to share any code you write using this framework. It makes no sense to me why a library would be AGPL licensed, LGPL is what I expect libraries to be, of course I'm not sure how the LGPL applies to Python, but I'm usually all in for MIT License.
> It makes no sense to me why a library would be AGPL licensed
> AGPL means you have to share any code you write using this framework
I think you've found the reason?
> AGPL means you have to share any code you write using this framework
I think you've found the reason?
But you're using this code in any application you make, so you can't use it commercially.. AGPL isn't made with libraries in mind...
> But you're using this code in any application you make, so you can't use it commercially.
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.
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 have always disliked the “GPL doesn’t prohibit commercial use” argument. You know well why it isn’t practical to use for commercial purposes. You basically make any project using it into an unlimited full featured free trial.
> I have always disliked the “GPL doesn’t prohibit commercial use” argument. You know well why it isn’t practical to use for commercial purposes. You basically make any project using it into an unlimited full featured free trial.
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.
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.
How competitive would Google or Facebook be if all of their code were fully open sourced?
I don’t know about google or Facebook but I imagine I could argue the secret sauce is configuration which (I anal) I imagine is not something you’d have to release under any GPL. The threat isn’t so much that someone will build a competing google as much as I think it is someone will game our system. Just my guess.
It breaks the pay-per-copy model, which is realistically the only one that is viable for a lot of proprietary software.
If there were commercial restrictions then it wouldn't be a free software licence. You're free to use the software for any purpose.
And you are forced to give it away for free if asked to.
More importantly it means you have to share any modifications you make to the library itself. This is good for us. Sharing is good.
sharing forced by license is not good.
Why? It's worked pretty well so far. We wouldn't have free software at all without it.
There's plenty of open source projects that don't force the sharing of code and are still successful. I work for a company that works with open source projects and we do from time to time contribute fixes back to projects we depend on, it's not liable to maintain a fork that you have to maintain back ports for, especially as the main project gets reworked.
In this case, AGPL seems to be an open source veneer on a free during development license.
Or you buy a commercial license from them. They write they made this choice explicitly to make a profit.
"one language only" if you don't count the javascript, html and css.
I wouldn't label HTML and CSS as languages. Also, the fact that python code is transpiled to JavaScript, does not mean you're writing 'JavaScript', in the same way that writing C code isn't the same as writing assembly.
They're not programming languages, but they are widely considered languages. HTML stands for hypertext markup language.
Just out of curiosity, does your response actually address the point I was making?
Just because C compiles to machine code doesn't mean that your pure-C code base isn't built in only one language.
> "one language only" if you don't count the javascript, html and css.
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.
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.
"One language only" is a marketing slogan. It's slightly misleading, since it doesn't look like you can implement meaningful applications in 100% Python or get away with zero knowledge of HTML and JS.
But it may be close, like you can spend 90% of your development time on Python, and write JS components in the remaining 10%.
But it may be close, like you can spend 90% of your development time on Python, and write JS components in the remaining 10%.
Knowledge of HTML, sure. But I've definitely built useful tooling in dash (similar project) without writing any JavaScript.
The post title is misleading.
> The post title is misleading.
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.
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.
What do you think would be a better title? I read "web apps" I think html, css, and js. I wasn't expecting (nor would I want to) to ship Python to the browser.
That might be what's being lost in translation here. Python is the development language. If we're to analogize, HTML/JS/CSS would be the runtime stack. Perhaps this is what's lost on mruniverse
Leave out the "one language only (Python)" part and it would be fine. Otherwise it's clickbait.
I'm three-fourths into the tutorial and I have yet to see a need to write html, css, and js.
https://www.reahl.org/docs/4.0/devmanual/ownwidget.d.html?hi...
About half-way down is "Write code for a JavaScript widget"
About half-way down is "Write code for a JavaScript widget"
Yes, for cases when an existing widget doesn't do what you want it to do.
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.
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.
Just take out the "one language only (Python)" part.
What's wrong with simply "Reahl 4.0: Build web apps in Python".
It's clear and truthful.
What's wrong with simply "Reahl 4.0: Build web apps in Python".
It's clear and truthful.
Because the key difference and value add is about not using other languages. Your title wouldn't clarify that to me.
Heh, good spot. It uses jQuery and jQuery UI.
[deleted]
Be careful. This is licensed under the AGPL, which basically makes it unusable. Or a commercial license can be purchased.
"Unusable" seems quite strong. It's usable for open source projects.
Sort of. It's only really usable for those who want to apply the same restrictions to their users/contributors.
Having to pay to use software commercially makes it unusable?
I'm surprised GitHub doesn't show this on the repository it just says "View License" but I guess they don't allow using AGPL when creating a repository.
They do support showing AGPL 3.0, but it has to be either in a LICENSE.txt or LICENSE.md. This project just has it in a file called LICENSE. https://help.github.com/articles/licensing-a-repository/
I noticed they stopped displaying licences on all repos recently. Everything says "view licence" now.
Why would they not allow AGPL? It's a perfectly valid free software licence.
Why would they not allow AGPL? It's a perfectly valid free software licence.
[deleted]
At first glance this looks like an interesting take at pulling a lot of the functionality back to the Python side of the web application.
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.
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.
I feel bad about projects like these, I really do. I'm sure a lot of effort have been put in and it probably satisfies what OP wants to do. But in the end, no one serious would ever consider using it.
Would anyone serious use this as the frontend for a customer facing website?
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.
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.
>But in the end, no one serious would ever consider using it.
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!!!).
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!!!).
Transpiling to JavaScript is a bug on the web, not a feature. node and npm is a shit show. Having to deal with it a couple days ago. I wish that entire ecosystem would just die.
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.
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.
I think this is a symptom of being accessible not the language or its tools. NPM is fantastic and anytime I use Go or anything like that I miss it sorely.
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 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.
Npm might be a good tool like pip. But unlike pip it encourages installing shit.
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.
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.
I don't think it is possible to separate language from tools or community. Those things are always together.
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.
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.
>I don't think it is possible to separate language from tools or community. Those things are always together.
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 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.
> changing prototype of "array" object is an acceptable thing to do
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.
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.
>Uhh, no? I code in JS every day and do nothing of the sort, and I would object if I saw it.
If you use Babel you already have that, and just don't know about it. Most "upcoming features" shims do just that.
If you use Babel you already have that, and just don't know about it. Most "upcoming features" shims do just that.
JavaScript is a god language. Changing Array.prototype is very much considered an antipattern, except in the case of shims, where it's really useful. JavaScript is reinventing itself, introducing a nice, traditional OOP facade with `class`, and making improvements to functional-ish programming with `let` (as opposed to `var`), arrow functions, and object and array destructuring. The DOM is still very much a "try to display something at all costs" mess that doesn't at all fail fast, but most of the things that you want to happen are indeed happening!
Well, Go is not a great example for dependency management either. That’s like saying how much you miss being slapped in the face after now being punched in the face.
>node and npm is a shit show. Having to deal with it a couple days ago. I wish that entire ecosystem would just die.
"I had a bad experience (being unexperienced and only delving into that ecosystem a couple days ago) so it's bad"
"I had a bad experience (being unexperienced and only delving into that ecosystem a couple days ago) so it's bad"
Or delving into it 16 years ago, teaching classes on it in college. So a little bit longer than a few days and while not a complete expert I can say I have some experience.
How about you? Do you consider yourself a senior after a couple of years of js?
How about you? Do you consider yourself a senior after a couple of years of js?
Well, I've did JS since 2000, so I'd consider myself a senior. There's lots to learn, and early Node ecosystem was immature, but it's today quite mature, well supported, with a steady update cycle, good backwards compatibility, and no worse than most of the other options.
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 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.
You can, but actually seeing it in the wild is rare. I consider myself full stack, but I try to avoid anything js because I'm inhereting someone elses shit ecosystem.
If I was forced to on a couple projects I've seen I'd ask for 10k raise.
If I was forced to on a couple projects I've seen I'd ask for 10k raise.
>I'll be downvoted to hell, but whatever. Js sucks
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?
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?
you_owe_me(1)
Before GWT, there was Wt framework (C++); and then JWt (Java), which do the server and clientsides (with widgets in a tree).
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.
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.
[deleted]
>But in the end, no one serious would ever consider using it.
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.
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.
Yeah, we've been there before with other libraries (GWT and others). It never works well.
Can you add some more here? Personally I'd probably not use this as I'm already using something with the same aim (dash), I certainly use a project like this for serious things.
I think what OP means is that for someone whose goal is to start a successful business, using a more obscure and new framework is akin to shooting yourself in the foot. There's nothing significant enough that a framework like this provides that justifies 1) the difficulty finding people with appropriate experience, 2) relying on something that may become unmaintained, and 3) an immature ecosystem that means having to deal with tricky problems as you build more complex functionality because you're among the first people to need it.
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.
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.
Obscure, yes because it's version 4.0.0 and it's around since 2006 and I never heard about it. New, no.
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.
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.
And for a good reason. These frameworks usually make development much harder than simply using JS directly.
Quite similar to Plotly Dash, but a worse license.
https://plot.ly/products/dash/
Dash is awesome for early stage , production ready prototyping.
Dash is awesome for early stage , production ready prototyping.
Worked with Dash this summer, its great but it's primarily intended to work with Dash components to display graphs and controls, not really for a generic web application.
The state management between the browser and the dash backend is not intended to be touched by a user.
The state management between the browser and the dash backend is not intended to be touched by a user.
Dash is awesome, frankly so is most of the work Plotly does. Chris, Dash's primary maintainer makes it better literally every day.
With „worse“ you mean what exactly?
Probably just „not fitting my personal needs and ideas“? That doesn’t make something generally worse... or can you tell me how it’s bad for me?
Companies are usually wary of AGPL. e.g.:
https://opensource.google.com/docs/using/agpl-policy/
https://opensource.google.com/docs/using/agpl-policy/
That just means „not suited for everyones needs and taste“ - tge same goes for another license that a company chose. Others like it less.
Exactly. And that's what the comment you replied to said. For them, it was worse for their "needs and taste" but you wanted clarification. Now you're saying the clarification is obvious so I don't know what's your point.
Companies trying to make money off somebody else's work are not the only consideration when choosing a license.
So how does this work? So is this like a templating where instead of writing a template file, you write an app using widgets and element functions that the framework provides and then stitch together an HTML page when requested and send to the browser?
It seems to me that html css and JavaScript are better suited for the job than Python, if you want to do anything complex at all. But I’m probably wrong.
Speaking as a python developer who uses Javascript and CSS only when necessary, yes, you are correct. It's not the fact that it's JS/CSS that's annoying to me about such work, and nothing about it gets better if you use python instead.
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.
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.
It’s a bit like the 8 bit computer age: You can get by in a high level view, but the performance might not be enough or you’re missing out on some features where you need direct access.
Given the immense speed of today’s computers, brute force might be enough, though.
Given the immense speed of today’s computers, brute force might be enough, though.
https://github.com/jeluard/lucuma Clojure
https://github.com/greencatsoft/scales Scala