D4no0
Any must have libraries lacking from elixir?
I currently have some free time and looking to create a library for elixir. The thing that always hold me back is trying to come up with an idea of a library that could be truly useful in elixir, I want to avoid creating a library for the sake of it. The things I am looking for are:
- The library should be lacking from elixir/erlang or must be re-implemented from the scratch: I don’t want to create an elixir wrapper for an existing erlang library or maintain an already created library;
- The library should be used: this points to the thing previously mentioned, I don’t want to create a library for the sake of writing some code;
- The library should make sense in elixir ecosystem: I want to avoid creating a library that would have no place in elixir ecosystem.
If you have any interesting ideas, let me know.
Most Liked
felix-starman
One that’s always been a small but annoying one is PDF manipulation (reading/updating) and writing that doesn’t rely on wkhtmltopdf.
There’s plenty of generation libraries, but not many, if any, that can do both.
For comparison I was imagining an equivalent to Hexapdf in the Ruby world: https://hexapdf.gettalong.org/
The negative is the PDF2.0 docs have to be bought (like $300 to the org that maintains them), but the 1.7 docs are freely available.
Hexapdf’s source is OO obviously but generally alright to read, but when I looked into it, the 1.7 docs for the spec aren’t too bad just… it’s a lot.
Separately, I also wanted to do HTML to PDF that didn’t require node. I lightly looked into wrapping a rust library, like calling the Servo core libraries that power Firefox, but when I last looked a couple years ago, I couldn’t find the right place.
dimitarvp
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}
Eiji
“Yeah”, we write thousands of local Phoenix servers just for creating apps with access to local drive …
Sorry, but I really do not understand your point.
Do we have even 1% of web applications that have native app look each having an awesome browser extension that integrates with DE/OS? I don’t know even one. There is a generic KDE/Plasma browser integration for example for multimedia handling, but still such integration is just like a drop in the ocean.
Also with such argument why we are developing? There is a Google, it’s used by most people and there is no need to have other one, right? I don’t think so … “Smart” algorithms (that causes more problems than helps for me) based on all around spying. I would like to write lots of tiny pet projects that are not Phoenix servers, do not require a CSS framework (which does not integrates with theme of my DE/OS) or spend lots of time to style everything on my own in CSS.
And once again, regardless of we ask for wxwidgets or web apps … What about Elixir part? My proposal was to have GUI in Elixir. Not with C/C++ bindings, not with CSS/JavaScript, but Elixir that have every component as separate process, that have 10x less LOC, …
Honestly I really don’t like when people tries to force using web apps to everything even when those completely does not Also I don’t like starting too much servers on different ports. Maintain such an environment is like a hell. I either need to have a terminal in background for each app just to press Ctrl+C or kill a process that’s not currently on any terminal. Similarly having many browser tabs for a sake of having app in background is like a bad joke. I honestly prefer a native app, with ability to minimize or “close to tray” option. For many such things web apps are extremely uncomfortable.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









