DEV Community: Daniel Bergholz

Announcing CourseShelf: Rotten Tomatoes for Online Learning

Daniel Bergholz — Wed, 21 Jan 2026 22:10:59 +0000

Back in 2019, I created TechSchool, an open-source platform to help people find free programming courses. The idea was simple: fight back against predatory coding bootcamps that charge thousands of dollars for content that's often worse than what's available for free on YouTube.

TechSchool worked. People found great courses. The community grew. But over time, I started noticing something.

The limitations of TechSchool

TechSchool had two big problems:

One, it was limited to tech. My friend who wanted to learn guitar couldn't use it. My mom who wanted to learn cooking couldn't use it. The core idea of community-curated courses was valuable, but I was artificially limiting who could benefit from it.

Two, adding new courses required opening a Pull Request on GitHub. Great for developers, terrible for everyone else. Most people who want to learn don't know what Git is, and they shouldn't have to.

I kept thinking: what if we could build something bigger? A place where anyone could discover quality courses in any subject, reviewed by real learners instead of marketing departments?

Enter CourseShelf

CourseShelf is the spiritual successor to TechSchool. Think of it as Rotten Tomatoes for online learning.

Here's the core idea: when you're looking for a movie to watch, you check Rotten Tomatoes or IMDb. You trust the crowd more than the trailer. Why should finding a good course be any different?

Right now, if you want to learn something new, you either:

Trust the platform's algorithm (which prioritizes engagement, not quality)
Trust sponsored reviews (which are basically ads)
Hope you get lucky

CourseShelf fixes this by letting real learners review and rate courses. No fake reviews. No sponsored content. Just honest opinions from people who actually completed the course.

Website: https://thecourseshelf.com

What you can do on CourseShelf

Here's a quick overview of the features:

Discover courses across any subject, not just tech
Read and write reviews with star ratings
Save courses to your library to track what you want to learn
Create playlists to curate learning paths for yourself or others
Follow other learners to see what they're learning and recommending
Verify your channel if you're a course creator on YouTube

Right now, the platform supports YouTube courses and books. We have plans to add support for other platforms like Coursera, Skillshare, and Domestika in the future.

For course creators

If you're a content creator, CourseShelf has something special for you. You can verify your YouTube channel and get a verified badge on your profile. This helps learners identify official creators and gives you credibility.

Verified creators also get access to analytics: see how many people are viewing your courses, what they're saying in reviews, and how you compare to others in your category.

I created TechSchool because I was frustrated that my free courses had fewer views than paid garbage. CourseShelf is my attempt to fix the discoverability problem for all creators who are putting out quality content.

The tech stack

I built CourseShelf using Elixir and Phoenix with React and TypeScript on the frontend via Inertia.js. If you've read my blog post about leaving React for Rails and then Elixir, you know this is the stack I fell in love with.

Phoenix gives me the productivity of Rails with the performance and reliability of the Erlang VM. Inertia.js lets me use React without the complexity of building a separate API. It's the best of both worlds.

Disclaimer

CourseShelf is currently in beta. We're actively adding features, fixing bugs, and improving the experience based on feedback. If you find something broken or have a suggestion, please let me know!

Some features are limited during beta, but the core experience of discovering and reviewing courses is fully functional.

Join the community

I built TechSchool because I believe tech education should be accessible to everyone. I'm building CourseShelf because I believe all education should be accessible to everyone.

If you're a self-taught learner, a course creator, or just someone who's tired of wasting money on bad courses, give CourseShelf a try. And if you know a great course that deserves more attention, add it to the platform!

Let's build the largest community-curated database of online courses together. We are all gonna make it 🔥

Stay up to date with new features and announcements:

Twitter: @courseshelf
LinkedIn: CourseShelf

Thank you

If you reached the end of this post, thank you for your time. Building in public is scary, but seeing people use something I created makes it worth it.

Have questions? Want to chat? Find me on Twitter @danielbergholz or drop me an email.

See you on CourseShelf!

My AI-Powered Workflow for Writing Elixir and Phoenix with Windsurf

Daniel Bergholz — Mon, 10 Mar 2025 14:41:03 +0000

There's a ton of stuff out there about using AI to write JavaScript and Next.js code, but what about Elixir and Phoenix? Are they getting left behind in the LLM code generation game? Well, yes and no. Can we make it better? Definitely. Is it worth the effort? Hell yeah. And can we actually become those legendary 10x engineers by writing Elixir with AI-powered tools like Cursor or Windsurf? You bet we can!

First, why Windsurf and not Cursor?

This year I tried using both Cursor and Windsurf for a month to see which one I'd stick with. The code they generated was pretty much the same (not surprising since they both use Claude 3.5 Sonnet). But Windsurf was better at understanding my codebase and grabbing ideas from my existing files, plus its UI just felt smoother and more intuitive. Honestly though, these AI tools are copying each other's features so quickly that it probably doesn't matter which one you pick - they're both solid options.

Does AI generate good Elixir and Phoenix code?

AI can handle the basics pretty well. Need a simple controller that renders a page? Or a basic LiveView with a bit of server-side state? Claude's got you covered.

But here's the thing - the more niche your tech stack gets, the less reliable AI becomes. Take my setup for example: I use Elixir, Phoenix, React, and Inertia for my side projects. The Inertia adapter for Phoenix is super new and not widely adopted yet (which is a shame - this combo is incredibly productive and performant). There's just no way current AI models have enough training data on this specific stack to generate useful code. The more specialized your tools, the more you'll need to rely on your own expertise rather than AI assistance.

This isn't just an Elixir thing - it's the same story with any tech that hasn't gone mainstream yet. Languages like Zig, Gleam, or Scala (and whatever frameworks people build with them) just don't have nearly as much code floating around online as JavaScript or Python do.

How to improve?

I mainly use two features in Windsurf: memories and rules.

Memories are like Windsurf's personalized notepad. Did Claude mess up by using assign/3 instead of assign_prop/3 inside a controller to pass Elixir data to React? Just point out the mistake. If Windsurf thinks it's important, it'll remember this for your entire coding session and avoid repeating the error.

You can be direct about it too: "Hey, you got X wrong. The correct way is Y. Please create a memory for this."

Rules are more permanent and explicit. Just create a .windsurfrules file in your project's root directory with specific instructions (similar to how .cursorrules works). These rules will guide Windsurf every time it helps with your code.

Here is my current .windsurfrules for Phoenix + Inertia:

You are an expert in Elixir, Phoenix, PostgreSQL, JavaScript, TypeScript, React, Inertia, and Tailwind CSS.

# Elixir and Phoenix Usage

- In controllers, use `assign_prop/3` to assign props to the Inertia page and then `render_inertia/2` to render Inertia pages.
- In controllers tests, use `inertia_component/1` to assert the component name and `inertia_props/1` to assert the props.
- When generating migrations, use `mix ecto.gen.migration <name>`
- Use plural form for context modules (e.g., "Users" for users table)
- Use singular form for schema modules (e.g., "User" for users table)
- Context files are usually inside a folder named after the resource (e.g., lib/my_app/users.ex)
- Schema files are usually inside a folder named after the resource (e.g., lib/my_app/users/user.ex)
- Prefer keyword-based queries over pipe-based queries
  - For example, use `from(u in User, where: u.age > 18, select: u)` over `User |> where(age: 18) |> select([u], u)`
- Use `dbg/1` to debug code.

# React and Inertia Usage

- Pages are in assets/js/pages. Use default export for pages.
- Components are in assets/js/components. Use named exports for components.
- Utils are in assets/js/lib.
- Inside pages, get the props from the controller as regular props from the function argument.
- When dealing with forms, use the `useForm` hook from Inertia
- Use absolute paths for local imports using `@/`
- If you need to merge tailwind classes, use the `cn` function from assets/js/lib/utils.ts.
- Import Radix components from "radix-ui", not from "@radix-ui/react-dialog" or "@radix-ui/react-button" etc.
- Always create the mobile version of the component along with the desktop version.
- Use lucide-react for icons.
- Use kebab-case for file names.
- If the page or component uses a type for a resource from the database, like users or courses, create the type in the assets/js/types folder.
- Prefer types over interfaces.

# General Usage

- When debugging data from the database, if the postgres_my_app MCP is not avaiable, use `psql my_app_dev -c "<your query>"` to connect to the database and then run the query. There is also the my_app_test database for testing.
- Use the `mix check` command after generating lots of files to check the Elixir and React code for errors and code quality. If you encounter format errors, use `mix format` to fix them.
- If any of my requests are not clear, ask me to clarify.
- If you have better suggestions, feel free to suggest them.

Getting Up-to-Date Info

This is a super underrated feature when working with frameworks that change all the time (like Next.js) or more niche ones (like Phoenix). Remember: AI is great at general knowledge, but the more specific you go, the less likely it'll get things right. To fix this, just use the @web directive and drop in links to any documentation you think is relevant.

Sanity Check After a Long Coding Session

It's all fun and games when Claude spits out 20 new files and everything looks fine. But are you actually checking all these files for formatting issues, type errors, or compilation warnings? And how do you make sure your code quality isn't tanking over time? Sometimes AI misunderstands what you want and goes off on a tangent, potentially wrecking hours of your hard work.

That's why I made a simple script called "check" (my mental "sanity check") that I ask Claude to run after long coding sessions to make sure everything's still good.

# mix.exs

defp aliases do
  [
    check: [
      "format --check-formatted",
      "cmd npm run typecheck --prefix assets",
      "deps.unlock --check-unused",
      "compile --warnings-as-errors",
      "credo --strict"
    ]
  ]
end

This script does a few key things: checks for formatting issues (my .windsurfrules file tells Claude to just run mix format to fix these), runs the "typecheck" script from my NPM project (React + Inertia) in the assets folder, looks for unused dependencies, checks for compilation warnings like unused variables or aliases, and finally runs credo in strict mode to catch problems like oversized functions or deeply nested conditionals.

This way, you can sleep easy knowing your app not only works but also has solid code quality with no warnings or errors hanging around. This is just my version of the check command - feel free to create your own with checks that make sense for your project. And if you want Claude to run both the "check" script and your tests after generating code, just add that rule to your .windsurfrules file!

A Word of Caution

This pro tip isn't specific to Elixir, but worth mentioning: be careful with generating code using AI - it can get expensive fast. Don't let the $15/month price tag fool you. This month alone I bought extra credits for Windsurf 3 times ($10 per 300 new credits). That brought my monthly cost to $45!

How to avoid this? My rule is simple: only ask Claude to generate code once I'm really confident about what I want to build. If you have a clear PRD (Product Requirements Document), there's a 95% chance Claude will "one shot" the solution. This is way better than going back and forth, generating code, rejecting it, and generating again.

TL;DR: Spend more time planning rather than generating code. In this new era, code has become a "low level thing" that machines generate, while we humans can focus on higher level problems like crafting a good plan for an MVP, figuring out what users actually want, achieving product-market fit for our startup, etc.

Moral of the story

Look, AI definitely has some blind spots with Elixir and Phoenix code - but as I've shown throughout this post, there are some pretty simple workarounds for most of these issues.

From my experience, the productivity boost is totally worth dealing with these little hiccups. That mythical "10x engineer" everyone talks about? It's not just hype - anyone can get there if they're willing to embrace these new tools.

The real trick is keeping an open mind and constantly trying new stuff. Don't get stuck doing things the old way just because that's how you've always done it.

Announcing TechSchool: A free and open-source platform to learn programming

Daniel Bergholz — Tue, 05 Mar 2024 22:52:54 +0000

Since 2019 I have published free courses on my YouTube channel. Many times, people have commented on my videos something like "Wow, this course is amazing! It's a lot better than the expensive course I purchased!". I started reflecting after that. Why on earth is someone getting paid thousands of dollars selling a course that is worse than the one I made for free? Also, why does my course only have 100 views on YouTube? This isn't fair.

Identifying the problem

There are lots of people who want to learn programming and also lots of free courses available. However, most of the time, these two groups don't meet each other.

Why? Two reasons. One is that multiple VC-backed predatory coding bootcamps spend millions of dollars targeting newcomers and telling them that the only way to get into the industry is by spending all their money on expensive online courses. Two, the YouTube algorithm is super hard to master. If you recently created a channel, it can take years to reach a bigger audience.

The solution

What if we could easily find all the free courses out there without the YouTube algorithm standing in our way? That's where TechSchool steps in. It is a platform that contains all the free content that might be flying under the radar. It is also open-source, which means anyone who knows a cool course can easily open a PR to add it.

Website: https://techschool.dev
Discord: https://discord.gg/C4abRX5skH
GitHub: https://github.com/danielbergholz/techschool.dev

Let's fight back against the expensive barrier to entry! Tech education should be free and accessible to everyone! We are all gonna make it 🔥

Disclaimer

TechSchool is forever a work in progress. We are all collectively adding more content over time, so if you don't like the options available right now, wait a couple of weeks and then re-visit the website! I'm sure you'll find something new.

The tech stack

I have it all explained on the README, but in summary, I decided to use Elixir and Phoenix, because it's a freaking AWESOME combo. I'm also using Live View on all pages, so hopefully the transition between them is super smooth!

From Next.js to Rails then Elixir: My journey through React.js burnout

Daniel Bergholz — Wed, 10 Jan 2024 23:29:41 +0000

I've been a web developer since 2019. I used React.js and React-based frameworks like Gatsby, Next, Remix, Astro, and Hydrogen. I've never been fully content with any of these tools, but, as a beginner who was deep into the JS ecosystem, all that I could hear from my peers was something along those lines: "This is the way, any other programming language is either slow or old".

As a result, I got used to a huge amount of complexity: Multiple separate repositories, thousands of libraries and frameworks to achieve simple things, GraphQL, microservices, serverless, static site generation, incremental static regeneration, partial hydration, redux, redux-thunk, babel, webpack, react server components, server actions, etc. This list could go on for another 10 minutes.

Until one day I said ENOUGH IS ENOUGH! Let's take a look at the complete timeline of me slowly going mad. This will take a while, feel free to make some coffee before the long read!

The timeline of the burnout

Gatsby.js

I remember finishing my bootcamp and thinking: "Finally I'm able to build my portfolio!", and so I did. There was only one small problem, I wanted to index on Google, but using the good old create-react-app made this mission nearly impossible. Soon I learned about SEO and React's hydration cycle, which led me to the "solution" of this problem: Gatsby.js. The idea of static site generation was simply revolutionary for me back then, after all, nothing is faster than pre-rendered HTML files, right?

I decided to learn this new framework by reading the docs and let me tell you, this was NOT a fun experience. I have never heard of GraphQL before, and apparently, you needed it to generate all the static files (what the hell???). I asked some of my internet friends if having a hard time learning all of this overengineered crap was normal, and they replied with "Skill issue, try harder!". So I tried harder, and after finally learning it, I ported my personal website to Gatsby.

Most of my pages were successfully indexed on Google, and for a couple of months, I was extremely satisfied with the result. Then another problem appeared: A LOT of my developer friends started saying "Gatsby is dead! Next was created to simplify static site generation and also provide server-side rendering".

Next.js

I took a quick glance over the Next documentation and immediately fell in love. I was able to do the same things as Gatsby without GraphQL and with a third of the code! Once again, I ported my portfolio to another framework: Next.

This time I truly had a wonderful experience. Deploying to Vercel was a breeze, the getStaticProps and getServerSideProps functions were simple, yet extremely powerful, I could choose the rendering style per page, a lot of flexibility in general.

Unfortunately, something I learned the hard way: In the JavaScript ecosystem, all the good things come to an end.

Remix

I remember extremely well when Remix was announced. Multiple tech influencers started publishing content about it (as always). However, back then I read on the home page that it did not support static site generation, just server-side rendering, so I thought "Wait a sec, all those years investing on the JAMstack are thrown away here? No way, this framework ain't gonna last". However, to my surprise, not only did Remix survive, but it was acquired by Shopify and emerged as a prominent competitor to Next.

After a couple of months had passed, I decided to give it a try. And once again, I was surprised, the main motto of Remix is to use the web fundamentals, and not an overly complex caching system like Next. So the mental model I needed in my head when coding in Remix was 10 times simpler: No global state manager, just use the URL, fewer client-side states, move all that logic to the server, and use cookies, going full stack without a REST API in the middle is super easy, just move your database queries to the loader function.

Leaving the Matrix

Then, out of nowhere, the truth was presented to me, and I took the red pill. Multiple questions started emerging in my head: Isn't Remix just like all the other "old and boring" frameworks like Rails, Laravel, and Django? We have been doing fullstack web development with server-side rendering for decades, but the JavaScript mafia decided collectively that this approach was trash, and moving everything to the client was the future. Did the same mafia decide that Rails was right all along? And doing all those over-engineered monstrosities with JS frameworks was not the right move? I started questioning everything. This "new" way of doing web development was a lot simpler and faster.

I'm DONE with Next and Vercel

I reached my tipping point with Next.js app router. Here is a comprehensive list of everything wrong that Vercel is pushing to Next:

What was once simple: The getStaticProps and getServerSideProps functions, now became complex and cumbersome. Currently, there is no specific place to add your API calls or database queries, you can write them wherever you want! We started mixing the business logic with UI once again, after making the same mistake with PHP multiple years ago. Do frontend developers not learn from the past? What happens if I delete a button? Does this break my user authentication flow because the database call was inside it? Your front end should be 100% trashable and replaceable. The competitive advantage you have against your competitors is the business logic, which should be completely isolated from the UI layer.

Next is now server first. Which doesn't sound that bad right? After all, this solves the SEO issue and shows fresh content to the user immediately. The problem is that most of the existing Next codebases relied on client-side libraries, like Styled Components and a couple of global state managers. What does this mean? With breaking changes like this happening constantly, your app becomes legacy software in a couple of weeks instead of years. More time is spent to keep all dependencies up to date rather than doing what matters: Shipping features.
Vercel hired multiple React core team members from Meta. This presents a serious conflict of interest because these engineers are now (allegedly) shipping features that are beneficial to Next instead of prioritizing the ones that could help all the React-based frameworks like Remix.

I couldn't take it anymore. I said to myself: You know what? I am tired of re-learning the same framework over and over again, and I completely disagree with this new paradigm.

Not surprisingly, other content creators were going through a similar situation:

youtube.com

The Path to Enlightenment

TL;DR: I was extremely tired. After getting burned out from all the React tools, my journey for simpler web frameworks started. Here are the prerequisites I was looking for:

Batteries included
Convention over configuration
Good developer experience
Modern and performant frontend

My first instinct was to take a look at the top frameworks from the Stack Overflow Survey 2023. Immediately I cut out from the list anything JS, C# and Java related. I never had any desire to learn the last two, they look ugly and verbose. So the remaining options were: Laravel (PHP), Django (Python), Rails (Ruby), and Phoenix (Elixir).

Python is a language that I used during my Network Engineering degree and I had a very pleasant experience. Django seemed to follow the convention over configuration philosophy, but what turned me down from it ultimately was not having a good built-in tool to work on the front end. Most people on forums said they were using HTMX and Alpine, however, both are external dependencies that you need to install.

Giving up on Laravel was extremely hard because it has an amazing cost benefit, with hundreds of official packages to handle pretty much anything a startup might need, like hosting, authentication, stripe payments, etc. For the front end, they created inertia.js, a very simple and elegant way of keeping the high productivity and powers from Laravel while using React on the front end. To be 100% honest here, the only reason I didn't choose Laravel was because of PHP's syntax, it looks ugly as hell with a bunch of $ and -> everywhere.

Ruby on Rails

Ruby on Rails needs no introduction. It's the OG of web development frameworks, with the revolutionary "build a blog in 15 minutes", which is still impressive to this day. Before I start ranting about all of the problems I found, let's start with the good stuff.

Similar to Python, Ruby is that language that you can show to non-technical people and they will understand what the software is trying to do. It is by far the easiest to read and the most beautiful language I've ever seen. I quickly realized that writing visually pleasing code was a priority for the Rails team, and that was new to me.

Not to mention that Rails pretty much invented the "Batteries included" and "Convention over configuration" philosophies, so this wouldn't be a problem. Inside one single documentation, everything I needed for any type of web application was available.

On the frontend side, there is Hotwire, a very simple and lightweight approach to all the UX improvements provided by SPA frameworks. I've always been curious to test the limits of this library, it looks very promising.

Alright, so on paper Rails passed on all of the prerequisites I wanted on a framework. Let's try it! The first thing I tested locally was the rails scaffold command. And immediatly I was SHOCKED. One single command generates everything I need for a CRUD? No way!

On Node + React land, to achieve the same thing, I would need to manually write all the code (there are no generators here) and install a bunch of libraries like: Vite, prisma, express, react router, redux, redux-thunk, vitest, cypress, react testing library, zod, typescript, eslint, prettier, 1000 different plugins, and maybe even GraphQL or tRPC. Basically a package.json with 900 dependencies already.

After the initial shock from rails scaffold, I was shocked once again when I opened the code from the controller:

class ArticlesController < ApplicationController
  def index
    @articles = Article.all
  end

  def show
    @article = Article.find(params[:id])
  end

  def new
    @article = Article.new
  end

  def create
    @article = Article.new(article_params)

    if @article.save
      redirect_to @article
    else
      render :new, status: :unprocessable_entity
    end
  end

  def edit
    @article = Article.find(params[:id])
  end

  def update
    @article = Article.find(params[:id])

    if @article.update(article_params)
      redirect_to @article
    else
      render :edit, status: :unprocessable_entity
    end
  end

  def destroy
    @article = Article.find(params[:id])
    @article.destroy

    redirect_to root_path, status: :see_other
  end

  private
    def article_params
      params.require(:article).permit(:title, :body)
    end
end

Is this all of the backend code? Just a couple of lines? That's impossible! This is so simple that it looks like a "low code" tool. It's simple, elegant, and extremely readable, which is something we rarely find in the JS land.

Okay, okay, you must be thinking right now: "This crazy react dev from the internet said he ended up using Elixir, so there must be some things wrong with ruby!". And you are right my anonymous friend, there were some things that annoyed me quite a lot, let's talk about them.

First, we need to address the elephant in the room: Moving from React + Typescript to a dynamically typed language is not easy. From the moment I started writing code and no intellisense or dropdown filled with code suggestions show up on my VScode, I felt blind and lost. This is a terrible feeling, I could make a typo on a function name and didn't realize it until the website is in production! I know we can write tests, but this is the type of mistake that I want to identify immediatly on the IDE, and not during tests or deployment.

Another thing I thought I would like, but ended up hating it: Too much magic. Inside a Typescript codebase, I can click on top of any class or function, go to the source and see how it's implemented. On Rails, where the hell do I do validation (for example)? Do I create a private function inside the controller? Is there a especific folder for this? NOPE, the correct place to do it is inside the model. Why? Because that's how it works, you either adopt the convention or have a hard time writing ruby code. I simply cannot develop an "intuition" on how everything works under the hood, I have to blindly trust that the maintainers did a good job at organizing everything.

And to finish my frustrations, I started writing frontend code. How do I create components? Partials. How do I define the prop types of this component? There is no way to do that, you need to open it up and visually look for all the variables inside it. How about doing some interactivity? Creating states? Well, there is Hotwire with Stimulus, but as you can see, you need to manually create your "re-render" function, it doesn't figure out a way to re-render the page automatically after changing a state like React.

// src/controllers/slideshow_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static targets = [ "slide" ]

  initialize() {
    this.index = 0
    this.showCurrentSlide()
  }

  next() {
    this.index++
    this.showCurrentSlide()
  }

  previous() {
    this.index--
    this.showCurrentSlide()
  }

  showCurrentSlide() {
    this.slideTargets.forEach((element, index) => {
      element.hidden = index !== this.index
    })
  }
}

Once Again I got frustrated. I got reeeeeeeally close to finding the perfect framework! What is the next framework on my list that I wanted to try if Rails failed? Elixir.

Elixir and Phoenix

I have to be honest, I was running low on patience. I tried multiple different ecosystems, and I was almost convinced to just stick with Ruby on Rails and give up on my quest to perfection. Until a video appeared on my YouTube recommended section:

youtube.com

Hold on! Here we can see a React developer saying a bunch of nice things about functional programming, Elixir and Phoenix Live View. Maybe I should give it a try!

The first thing I did was open the documentation for Elixir and Phoenix, and I really enjoyed the fact that all packages are documented in the same way using Hex Docs, you just need to get used to one interface in order to learn new things.

Another good thing is that you can truly learn Elixir just reading the docs, no need for an expensive course! On every other ecosystem, I had to learn the language through a paid course and then learn the framework by reading the docs.

Then it was time to start writing code. Very quickly I understood that functional programming is very different from OOP. Let's do a small comparison:

// JS
const obj = {name: "daniel"}
obj.age = 25

// result: obj = {name: "daniel", age: 25}

# Elixir
obj = %{name: "daniel"}
obj = Map.put(obj, :age, 25)

# result: obj = %{name: "daniel", age: 25}

Or you could achieve the same thing with a simpler syntax using the pipe operator:

# Elixir with pipe operator
obj = %{name: "daniel"} |> Map.put(:age, 25)

# result: obj = %{name: "daniel", age: 25}

Initially you might find it less readable and more complex, but I promise that over time it makes sense! Well, at least for me it did. As a React developer, I got used to seeing multiple functions everywhere, even front end components are functions! Not to mention the fact that creating a class is sometimes viewed as a code smell by the JavaScript mafia. My brain was already "shaped" for this new paradigm, it just felt natural to me. Since my Network Engineering degree in university, I had several classes about object oriented programming, but it never "clicked". I couldn't model complex problems into classes and objects. Using multiple functions to "mutate" a variable over time is how I model things in my mind.

How about the main framework? Is Phoenix batteries included? Convention over configuration? YES IT IS! To be honest, the ecosystem is not at the same level as Rails, but it's 95% there. Unless you need an ultra-specific feature, Phoenix got you covered.

I was almost sold on Elixir, 2 things were missing from my list: Good developer experience and modern/performant front end code.

José Valim announced he was experimenting with adding types to the language, but Elixir doesn't have them currently, so I got concerned. How do I get intellisense and autocomplete without types? Soon I discovered these features aren't necessarily related. After installing the ElixirLS extension on VScode I was surprised. It's possible to define a function inside a random module on a random folder, import it somewhere else, and get the intellisense and documentation for it! I have those benefits from statically typed languages without the hassle of writing types, simply amazing!

My Future with Elixir: set-theoretic types - The Elixir programming language

We announce and explore the possibilities for bringing set-theoretic types into Elixir.

elixir-lang.org

My final concern on the frontend was addressed by Phoenix Live View. On the code side, this was the exact piece of the documentation's home page that convinced me:

You can define "props" to every component, and if the types mismatch, you get an error in your IDE, just like react! Impressive!

How about the UX? Is there a full page load whenever a user clicks on a link? Hell no! Live view establishes a WebSocket connection with the client, and then every page transition is just a content swap made through the Websocket, no new HTTP request is made. Also, all of the state is managed on the server side, which means that rich user experiences like Trello, which used to be very janky on the client side due to an excessive amount of javascript being loaded, are now super fast! Elixir handles all the complex state logic and sends the updated pieces of the page to the front end. Take a look at the full explanation here:

youtube.com

Since we are using WebSockets for builing the UI, creating "live" applications like Twitter takes only a couple of lines of code!

youtube.com

Conclusion

It's safe to say that the "perfect tech stack" doesn't exist. The silver bullet that solves all the problems is an illusion that we create in our minds to keep searching and building the most optimized tool.

However, at an individual level, the perfect stack does exist. Because each developer has preferences, and you can easily find a tool that fits your criteria. If you had a similar journey to mine, perfection might be Elixir and Phoenix! So give it a try, maybe you'll love it as much as I do now.

If you reached the end of this blog post, you are awesome! Thank you so much for your time, and I hope I could bring some value into your career.

DEV Community: Daniel Bergholz

Announcing CourseShelf: Rotten Tomatoes for Online Learning

The limitations of TechSchool

Enter CourseShelf

What you can do on CourseShelf

For course creators

The tech stack

Disclaimer

Join the community

Follow us

Thank you

My AI-Powered Workflow for Writing Elixir and Phoenix with Windsurf

First, why Windsurf and not Cursor?

Does AI generate good Elixir and Phoenix code?

How to improve?

Getting Up-to-Date Info

Sanity Check After a Long Coding Session

A Word of Caution

Moral of the story

Announcing TechSchool: A free and open-source platform to learn programming

Identifying the problem

The solution

Disclaimer

The tech stack

From Next.js to Rails then Elixir: My journey through React.js burnout

The timeline of the burnout

Gatsby.js

Next.js

Remix

Leaving the Matrix

I'm DONE with Next and Vercel

The Path to Enlightenment

Ruby on Rails

Elixir and Phoenix

My Future with Elixir: set-theoretic types - The Elixir programming language

Conclusion