Or which features of current frameworks you use you feel you couldn’t live without?
3 Likes
I don’t think it needs much, but an ORM is definitely on the must-have list.
4 Likes
I agree about a good ORM/DB tool Ohm! 
Some of the things I found useful recently:
A nice caching system
In Rails you can cache templates and templates for whole collections simply and automatically. This is great if you need to do anything that is remotely computational expensive. So for example, on the DT front-page, each postbit is cached - so computing the type of icon it needs, the colour, how the category names are displayed (sometimes just the single category, sometimes with the parent), putting together the links, etc are all just done once - until something actually changes. They are then served by Memcache. I think things like this (and Turbolinks) has helped Rails enormously.
Something like Turbolinks
Anything that makes a site load (or appear to load) fast is a huge plus imo.
Something like LiveView
The less we have to work with JS the better. Bonus that LV gives you real-time coolness!
Built in Auth
Since most apps will require auth, having a built in system (like Phoenix will) is really useful. It means library authors can assume a standardised system may be used and could mean better or more interesting packages.
Email - In & Out
Being able to easily send email (pop/smtp). Dealing with incoming email is becoming more and more important too imo. For example ISPs penalise you if you continue to send mail to addresses they’ve told you do not exist - so being able to work through these and prevent emails being sent accordingly is important.
3 Likes
Ability to degrade gracefully in the absence of JS
Still something that is missing from most web projects out there. Not cool. This is not only about surveillance, ads, trackers etc. – sometimes people are legitimately out and about (say on an archaeologist site) and they should be able to opt out of JS and the Web should be able to [minimally] serve them.
I’d like to see more frameworks allow something along those lines. Some of the app’s artifacts and functionality could be described with something akin to Rails / Phoenix templating language that varies its outputs depending on if the user’s browser has enabled JS.
5 Likes
With tech like Elixir / Phoenix, many times you won’t ever need cache. I recognize that both Redis and Memcached are very mature, serious and solid softwares but ideally you wouldn’t even have to reach for them.
Related to what I posted above: ideally you’d be able to have your framework cover you in the cases where JS is not supported. Sadly Turbolinks doesn’t care about that scenario and one has to take special care to serve JS-less assets with <noscript> tag themselves.
That IMO only works well in the BEAM but hey, always curious to see what other people come up with!
Yes, yes, yes, YES please! Setting up Devise / Pow in new projects can only be done so many times before you get sick of it.
Yep. Time for all this to be commoditized and you to only fill a single small config: if you want Mailgun, Sendgrid etc., what are your API credentials and that’s it. The rest should be handled automatically. It’s really high time for that.
3 Likes
Why won’t we need caching? If you take the example in my post above, the computations are done only once, if nothing changes the saved html/cache is served to the next person - no need to recompute everything, making it extremely fast. In Rails it happens on the collection as a whole as well as individual items in the collection - does the same or equivalent happen in Phoenix? If not I think adding something like this would make Phoenix even faster 
1 Like
With templates being inlined at compile time by Phoenix - which removes IO from the equation, arguably the most expensive part - I assume that the performance gain from caching would be negligible compared to Rails.
Also not to mention the unavoidable increase in complexity. 
3 Likes
Mostly because Phoenix/Ecto are so fast that you don’t even need to put stuff in cache, especially in an external service. Unless you get to highly structured multi-tiered data that are allowed to be stale for 1-2 seconds then simple naked cache-less Phoenix/Ecto code still take less time (<50ms) compared to storing stuff in Redis / memcached and fetching it from there.
…And, as usual, @wolf4earth articulated it better than me. 
2 Likes
That is very cool 
and I think most frameworks pre-compile templates now (Rails does in version 6) but when it comes to serving content, how does that help in the way that you can cache what’s actually served to the end user by the methods I described above?
Just to give you an example, on the postbits on our frontpage there are several things that have to be computed for each one:
- A regex is run on the titles to strip publisher names from book thread titles. Eg, “Great Book, Third Edition (PragProg)” becomes “Great Book, Third Edition”.
- The icon in the top right corner is worked out via the tag or section that thread is in
- The colour of the triangle is worked out depending on which section the thread is in
- The section links are adjusted depending on whether they have a parent category, and what the parent section is (sometimes we display the parent category, sometimes we don’t)
- Then you have the standard queries of getting all the data, the associated data (such as user/avatar/tags, etc)
- Then you construct urls from or format that data
That’s quite a lot of computations - that have to be done on each item in the entire collection - and that’s just the main trending bits, you then have all the other bits in the side columns. By caching and serving the output of these, and only updating the cache when something actually changes saves a huge amount of resources - since it’s all stored in memory (we allocate 10GB to the cache here).
And it’s really really easy to do (in Rails) - it does it all for you, you literally just do this:
<%= render partial: "shared/thread", collection: @todays_latest_topics, cached: true, as: :thread %>
…and it automatically reads from and expires caches for items that get updated (it caches the whole collection, as well as each individual item).
I think having something like this in Phoenix would be amazing 
3 Likes
Web frameworks are difficult to get right in my mind. You want them to be prescriptive, so you benefit from shared conventions when moving between projects, but flexible so you do not become restricted by the framework if your application moves in a direction counter to the framework itself. Ruby on Rails is a good example of a framework that has strong conventions, but can be a pain when you start to fight it.
I’ve been impressed with the care taken towards the Phoenix framework to keep things modular, as to avoid framework bloat, but also batteries (mostly) included for rapid iteration in the early stages of the project.
4 Likes
I agree whole heartedly with this. It’s always been my opinion that web applications that don’t work in lynx (which doesn’t provide JS) simply don’t work. But my bias has always been toward doing everything server-side instead of depending on clients.
3 Likes
That bias has been historically proven correct so I stand with you.
3 Likes
Yeah this, this is so so very crazy important to me as I tend to live in the CLI in a lot of places (literally no GUI). That’s why I like things like unpoly.com and so forth.
1 Like