TBF that’s very often a business decision. Most sensible programmers will immediately tell the business folk that web apps are an overkill and introduce dev overhead – as you mentioned, bootstraping web projects + writing CSS isn’t always a 1h affair, sadly, and is often an annoying busy work – but they will never care because when they ask what would it take to make a native app, to them it becomes a very simple math: “choose the lesser expense”, which is the web apps.
Can’t blame them, I get where they’re coming from but… nobody wants to pick up the torch. Including the companies that clearly showed they had THOUSANDS OF DEV SITTING IDLE yet they never made them do anything truly productive and area-progressing like, say, cross-platform GUI toolkits. Nah, let’s just keep butts in seats because we don’t want the other corp to hire them. And at the first sign of trouble, oh well, just fire them.
They are. We have collectively settled for the least common denominator. I think this highlights how dependent most programmers are – we are just wage slaves, let’s be real – and not the gods that can solve every problem AND be independent AND decide what they want to work on at any given time AND not be dependent on business people, as many old-school books envisioned the programmers (and scientists) would be. In TheBrightFuture™ that never came.
I don’t see a way out. Only if a bunch of tech people got super rich very early on but don’t want to retire and they open a research lab that works on such things and is being generously funded for decades, I think. As long as you have corporate or military interests in the equation, nothing will truly progress. Too many parties with vested interest to keep things as they are.
But we are moving to a pretty grim dystopia quickly though; I’ve met a good amount of people who freeze when they sit at a computer, trying to do stuff like “open an email” or “search for this”. I guess one day we might have altars to God Electron The Framework? And people will carry food and flowers to them and if their app crashes they’ll be like “God Electron works in mysterious ways”.
I am only half-joking. I am super salty at how quickly people learn to shrug off technology as a capricious deity.
Humanity can do much better than that.
{removes his philosopher hat and goes to brush his teeth}
Exactly! That’s why making GUI library as simple as Phoenix would be a big change on whole market. I just can’t say for others, so my main point was that many tiny pet projects would be much better after GUI enhancement.
It came! I really can’t imagine me working with other stack than Elixir/Phoenix in long term. I can complain on many things in that rotting world , but with Elixir I was able to make my dreams come true. That’s why regardless of everything I still have a hope … somewhere really deep … but I definitely have!
Ok, time for you José!
You too brother?
Definitely! Unfortunately system have a major bugs not fixed for years and unfortunately it’s going in really bad direction because of some extremes.
That’s said my proposal is pretty big. In short term I would rather go for things like:
That is certainly very true for myself as well, it just depends from what angle you are looking at it.
I find it hugely disappointing to still have to manually fling files. We should have generators that say “I want auth”, “I want users”, “I want multi-tenancy”, “I want background jobs”, “I want an API client, here’s the spec for it, generate 100% of the code with ability to handle HTTP 429 and with N retries”.
Etc. etc.
But no, most of what we do is: (1) read requirements, (2) sigh deeply because we know EXACTLY WHAT WE WILL DO IN THE NEXT THREE HOURS, and (3) shrug and get to it.
It can be much, much better.
For all the fancy AI talk I haven’t seen much improvements to dev workflows in the last several years apart from LSP and TreeSitter. They are wins, but marginal ones and I truly expected more.
what would you use libxo for? I wrote ~dch/ucl - sourcehut git which may do what you want already. Bonus points if you can tell me a better way to bundle libucl for linux etc, and double bonus points if you have ideas to improve it!
Honestly I understand where your frustration comes from, a lot of time simplicity is the key to success.
While I agree that creating the possibility for users to create easily UI is very powerful and is present only in some languages, I don’t think that native is doable by a single person. If we talk about complexity of such an integration, it is possibly years of work, a re-implementation of wxwidgets.
On the other hand, making custom UI components is much easier and you are guaranteed cross-platform integration out of the box, not mentioning having minimal bindings only for rendering. Maybe this could be settled in the middle by having a intermediate library for fetching native things like you mentioned earlier (like theme) and offering some kind of integration in the application.
I have pretty good idea of architecture and features required for a truly good and fast UI builder, however it is important to iron out these native integrations correctly, maybe I should open another thread for a discussion on that.
Supervise Chrome with holsee/chroxy or even put it in a lambda and autoscale by connection, each connection is served by 1 new lambda then use the remote protocol to get PDF out
It’s not about making something done, but it’s about starting it, with simplest demos showing others that’s in their range and that way build a community around it. scenic demos are more than enough already. Now there is need to be a fork or dependent library which aims desktop GUI. Linux, Elixir and many other awesome projects also weren’t started by thousands of developers working full-time.
Parsing it is really simple (css files parsing from gtk could be done later by community). All we need to do is to put those values into Elixir structs and draw component using this data. We don’t have to share everything. Step by step, today button, tomorrow checkbox and when people would see it more and more useful and actively developed then they would help on their own as well.
As said integrations are another topic. As long as the “core” library supports it we can delay them especially that some things like notifications we can draw on our own pretty simple.
Sounds good! I guess the next step is to investigate wether scenic is a good core for this kind of project, while it’s abstractions are good enough, I have the problem with GLFW that is used for rendering and user input, even to this day I was unable to start a scenic application on windows, not mentioning that GLFW doesn’t integrate well with touchscreen devices.
It would be amazing to have option to change it - like in some games there are choices for sdl, opengl or other render. Most probably we would need to fork scenic for this and make just this one feature configurable.
You can see a discussion we had on this topic here. From what I see, the framework is already using the concepts of backends, for example: GLFW driver.
What worries me more is the presence of NIFs, the problem with them is increased difficulty for cross-compilation, while scenic supports builds for generic architectures(x86-64) and arm64(rpi), it will become a problem with devices like android and new macs running on a different architecture. The most optimal solution seems to be what Nx is using currently: precompiled binaries.
The other problem I see with scenic, is that it was oriented as a standalone framework, much like phoenix, so most probably we won’t be able to use it as-is and we will have to either fork it or start from scratch.
Wasn’t that a compile-time dependency? As said like in game there should be an runtime option based on CLI argument or some kind of generic configuration window.
From my understanding, you have to use the OpenGL headers (at compile-time) that are written in C and represents the API to communicate with the GL runtime, that is either installed on the system or can be embedded.
To be fair now that I think of it, I have no idea on how the mechanism of communication works, in my mind it was always some kind of dark magic involving dynamic libraries linking.
Happy I read this comment — I ended up needing to do some research this evening to find a PDF generation library and ChromicPDF looks ideal. Are there good instructions anywhere about installing Chrome as a dependency in a Dockerfile, and is it a big dependency?
Lots of solid wisdom here. Good timing, as the tech giants shed many of the devs they have been hoarding.
Corporate accountants characterize development as an expense and employees as a liability, hence the tendency to revert to the lowest common open source tool (eg. Http, css, JavaScript)
Anything beyond is subject to personal initiative.
Most devs like to write code, so they dabble in a language until the project gets hard to manage.
Rather than stretch into new skills like testing and ci/cd to create more robust and powerful abstractions they jump to the next new language.
…Java, Kotlin, Ruby, Python, JavaScript, coffee script, typescript, golang, rust…
The madness continues.
Sometimes, a miracle. Some clear headed folks choose progress over activity, confidence over confusion.
Python has Django…
Erlang has Elixir…
Dart has Flet…
Elm has elm
JavaScript has jack shit (I couldn’t resist)
Just to nitpick a little, IMO Golang and Rust are anything but madness. They are very solid in what they do and they serve needs in their niche that other languages (Python and C/C++, correspondingly) have consistently failed to deliver.
Does that make the area in general more bloated? Yes but temporarily – a few decades. Even the Linux kernel devs started accepting that Rust is a better way to do systems programming and Rust has its foot on the door. It’ll only get more prevalent there with time.
If anything, it is the social dynamics like bias and people getting old and set in their ways that are the factors slowing down such processes to almost a halt.
It’s true what you say though, we need super good stacks in each language. It’s happening but at a glacial pace and I am regretting that I will not be alive to see all that coming together and finally turning machines into a commodity that we can all program with our own voice. But that would be at the time when a General AI (think Skynet) will be already existing so at that point programming itself will be unnecessary.
And people will carry food and flowers to them and if their app crashes they’ll be like “God Electron works in mysterious ways”.
I can complain on many things in that rotting world 
, but with 
then use the remote protocol to get PDF out
Most probably we would need to fork 
