Hello, it’s not yet another frameworks comparison question.
My specific use case is to create a web app which will have around 20-30 views (with many fields of information); it will need calculations and also report writing (pdf/word export of documents);
I am not interested in an SPA because it will mean to duplicate the huge Model on the front-end, so I’m looking for a solution with Server Side view rendering (even though it means the pages will be constantly reloaded on each change);
I thought that Java Enterprise Edition + JSF will make my life easy in this case. But the syntax, performance and the ‘fresh wave’ of an Elixir/Phoenix app seems also very tempting. I have experience in Java, but I can take some time to learn Elixir/Phoenix.
Basically, will Phoenix be appropriate to build large forms with validation, without me having to reinvent the wheel for each page? (The app won’t need a chat or other real-time features, which I know Elixir supports really well);
I understand the benefits of each framework, but I have to make a decision and I’d appreciate your help.
Thank you.
Where you may have more difficulty is with your desire to export to file formats such as MS Word. There are a few PDF libraries on hex.pm, but for formats such as word processing docs there are fewer options. librex exists, but does file conversion via a local install of libreoffice rather than allow direct generation of documents ala report writers. In this area, Java is going to have far more mature and feature-rich options for you.
If you can live with (or even help improve!) that, Elixir’s other benefits (including, but not limited to, developer satisfaction) make it a very attractive option for such things.
I remember the time where I’ve once generated cards with coupon codes with by drawing such cards in Inkscape (which produces SVG files), and writing the text I needed to replace between curly brackets ({{var}}) inside Inkscape, of course. Then, I would treat the whole SVG file as a Jinja template, and simple replace the text. After that, I don’t remember if I used Inkscape to export the SVG as PDF again or if I used Qt’s SVG renderer, but the whole idea of writing an SVG template directly in Inkscape was very cool.
I’ll probably get shot here, but I would choose Java for the libraries it already has IF you don’t have time to study all the workarounds such as generating your own xml for docx. Maybe you’ll need more strange ways to access different databases for generating those reports, maybe even legacy ones, if it is true then integrating Ecto and even pure drivers would cause a lot of pain. CRUD almost all web frameworks handles well. The problem also might come from the calculations, which kind are they? If they are some what heavy such as financial computation then Elixir might not suit good.
But since you want some better developer experience I would recommend Spring Boot with Kotlin, IntelliJ has a superb support for both of them, you get all libraries you need to do the strange things, a nice new syntax and null pointer avoidance from Kotlin.
Honestly, this is not really an issue unless you are really hitting heavy numerics (scientific; ml; transcoding …) and these days there are libraries with NIFs (natively compiled code) for the heavy lifting for many/most of these needs.
You should really open-source that. Elixir is still viewed as fringe tech by many people who are not well informed about its very strong background and making libraries that cover such real-life needs will remedy that false notion.
Most good Elixir devs understand that quite well. That’s why NIF bridges to hand-crafted and mega-fast computation libraries exist. Nobody around here is about “everything must be written in Elixir”. It is extremely good in a number of areas but where it is not, we should absolutely reach for another language.
Now that I can agree with. There are a number of huge legacy apps that utilize Oracle and people have been asking here and in SO how to handle those. Others as well.
While I would relentlessly question the value of a niche key-value store over Postgres – especially when the author clearly also wants joins, preloads and a ton of querying of different kinds (which all scream for a RDBMS and not a KV store) – I believe that making Elixir more widely accepted requires for it to be pluggable without much fuss in a legacy project.
Not really much to show about it, I quite literally just made some normal docx and xslx files in office, unzipped them, made them into eex templates, then just render the templates back out with the data and re-zip the contents, it’s really really simple… >.>
Might be worth a blog entry sometime perhaps.
That’s my very job, so I foreign wrap the oracle horrors into postgresql for a singular interface to it (and others). ^.^;
I think we got lost in traslation. I did not realize it was that simple and no, I don’t mind “low level” work at all. I very much like making bridges between technologies even if the job is hard and ugly. It’s a passion and I sacrificed money, patience and sleep for it many times.
I realize that now, sorry for wrong assumption. Still, a blog post documenting the steps you took will definitely help people.
That’s why I pointed as heavy financial, still there are NIF but the OP does not know very well Erlang to make use of NIFs or even write them as noted:
If the OP has time to learn NIFs then this disavantage can turn into an advantage since you hit C performance for calculation which are way better than common Java.
I also went to google to search on how to transform docx because I didn’t know it is xml, but as all xmls is super complicated with lots of schemas. But there are libraries for other languages, which you could use Ports send the message with the necessary context (data to render) and write the document on other language, such as Ruby or Javascript, the downside is that you’ll need another runtime installed
Thankfully one does not need to know erlang or anything special to use them. If you have used ets, or any other “:something” module names, you’ve “used erlang”, and the NIFs are hidden behind those APIs.
Yes, writing your own NIFs takes a bit more experience and some C or C++ chops, but if we look at libs like matrex it is just like using any other elixir code … but fast And that’s a library that challenges, and even beats in some ops, numpy!
Rust is another option via Rustler - write NIFs in Rust, which is safer than C/C++. I was able to get a toy NIF running with zero experience in just a few minutes, and Rust was also surprisingly accessible.
Ecto is the best framework I’ve ever seen for data validation and for general SQL integration. Total freedom and power without drudgery.
It can totally do this. Honestly all the discussion of NIFs etc is a major distraction. For business applications Elixir is more than adequate to the task of calculating fields, and Ecto is also really great at helping you push this down to the data tier without pain and drudgery. This isn’t about matrix calculation for scientific or big data applications.
Report writing is perhaps a weakness. If you have to do complicated reports with multi-level nesting and roll-up which Crystal or SSRS can totally crush, you may think its too much work to roll it yourself in Elixir. You could use an external reporting solution if you really need this functionality, and try to share some views so you don’t totally duplicate the data layer (but you will duplicate it anyway).
Absolutely this. I also mention to people that for hardcore number crunching they will have to reach to NIFs or Ports but the truth is, your app – and number of contracts, and revenue – has to be pretty ahead in terms of both technical and business development before you actually need to reach to lower-level language for more raw muscle.
I keep mentioning to people how I reduced the time for a singular report generation in Ruby – it was 2.5 - 3.0h before and ended up 7 - 15m afterwards (after I rewrote the reports in Elixir). Sure, not lightning fast but a 17x - 25x improvement nonetheless. Would a dedicated reporting software with an SQL GUI have done better? Absolutely. But that’s not the point – people often times need frictionless solutions and they need them yesterday.
Rust is a great shout, though if you are binding to existing libraries, paricularly C++, ot can be easier to just that route directly. But for new work from “while cloth” ruat via rustler is a very nice option indeee
I very much like making bridges between technologies even if the job is hard and ugly. It’s a passion and I sacrificed money, patience and sleep for it many times.
