DEV Community

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

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

Daniel Bergholz on January 10, 2024

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 ful...
Collapse
 
morphzg profile image
MorphZG

Definitelya high value post. Finaly something to read. Big respect. Thanks for sharing

Collapse
 
danielbergholz profile image
Daniel Bergholz

Thank you!

Collapse
 
lumsdendigital profile image
Ruaidhri Lumsden

Great post Daniel. It's interesting how similar or journeys have been so far - except that I've never been at all tempted by Ruby! I'm firmly in the Remix camp at the moment, and am quite happy with it at the moment, however you have inspired me to look into Elixir and Phoenix in greater detail.

I'm not in total agreement with all your points, I personally don't think that co-location is a bad thing.

You're right though, there's no such thing as the perfect tech stack, it's fun to keep looking though!

Collapse
 
danielbergholz profile image
Daniel Bergholz

I'm also in the Remix camp right now! I work primarily as a front-end developer, and my team uses Remix (Hydrogen to be more precise). And the developer experience from it is miles ahead of Next in my opinion. If Remix had batteries included (for the backend), I would still use it for my personal projects, but for my use cases I decided to move to Elixir + Phoenix

Collapse
 
lumsdendigital profile image
Ruaidhri Lumsden

It's good to hear something so positive about Hydrogen. I've got a potential e-commerce freelance job coming up and was considering it

Thread Thread
 
geni94 profile image
geni94

... all the great things for Hydrogen are coming from the 20 people who use it lol.

Collapse
 
lcmen profile image
Lucas Mendelowski

Thank you for sharing your thoughts!

Deploying Live view requires some additional caution, as restarting the server leads to state reload on the backend. There is built recovery solution for forms but custom components may require additional code. This is not a problem with Rails and Stimulus because state is stored in HTML.

Collapse
 
ankitsingh profile image
ANKIT SINGH • Edited

Finally, someone did a lot of hard work to write this. Daniel, I did the same. I started my journey in 2018 with React but slowly by the time 2020 Ruby on Rails took the tide, because of the market demand. Elixir is good, might try it someday.

Fun Fact this website is on Ruby on Rails. 😆

Collapse
 
peacechen profile image
Peace Chen

Frameworks are a double edged sword. They're convenient because they provide a lot boilerplate out of the box. However as you've noted, the big downside is that you're at the mercy of what the framework provides. If you stray from it, be prepared for much pain.

There's a place for frameworks. While they can hide some complexities, that can only go so far and is detrimental sometimes when debugging. There's no substitute for fundamental software engineering knowledge and experience.

Collapse
 
zaknarfen profile image
Renan Augusto Dembogurski

What about Blazor + .NET 8? I know you said no to C#, but the new version of Blazor blew me away. C# is improving drastically with every new version. The good thing about learning C# is that you can also make games with it, which is my hobby.

Collapse
 
danielbergholz profile image
Daniel Bergholz • Edited

To be honest, I was just too lazy to try C#, I never looked too deep into the language

Collapse
 
pppdns profile image
Denes Papp

you are misjudging C# my friend :) it's not the old and ugly Windows-related thing it was many years ago. It has become one of the most modern and sexy languages. The syntax is pretty much the same as Typescript. For example, writing a fully type safe hello world API is just 4 lines of code now.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();
Enter fullscreen mode Exit fullscreen mode

ASP.NET Core apps are now faster than Node.js apps and much much faster than PHP/Rails apps. Like 10x faster or more. They are pushing out new modern features quite often and the team has moved away from the clumsy old .NET platform to a new lightweight and easy to learn platform. It's like Node.js but easier, safer, and faster

Thread Thread
 
joshuaamaju profile image
Joshua Amaju

I can never get over MapGet in Microsoft related languages, looks so ugly

Collapse
 
kevgathuku profile image
Kevin Gathuku

Keeping up with the JS / React ecosystem is a huge challenge. Building a project and coming back to it after 2 months and nothing works anymore since there’s some new paradigm. Gave up on it entirely too! 😅

Collapse
 
danielbergholz profile image
Daniel Bergholz

Exactly my feeling as well! I can get a Ruby on Rails codebase from 5 years ago and it still works. But If I go back to a 1-month-old JS codebase, nothing works

Collapse
 
nicoka11 profile image
Nicoka11

After trying Next (production level at work), SvelteKit, and NuxtJs.
I would say the best to use is Nuxt for 3 simple reasons :

  • The docs are amazing and complete
  • The framework itself is really minimalist by default but extends quite a lot to suit your needs
  • It doesn't change as often as Svelte or even worse React (freaking server components)
Collapse
 
danielbergholz profile image
Daniel Bergholz

I’ve heard good things about Nuxt!

Collapse
 
vincent23 profile image
Vincent

Great post and this is exactly why I quit JS web development years ago. It really is a job for code monkeys that somehow pays well these days. There are so many other, a lot more interesting things going on in the world besides new JS frameworks.

Collapse
 
danielbergholz profile image
Daniel Bergholz

Agreed 100%

Collapse
 
entrptaher profile image
Md Abu Taher

Being a JS developer, I have felt this burnout a few times. These frameworks are simply too much. Only a few frameworks and libraries remain critically unchanged over time, and provide backward compatibility.

Sometimes I have this urge to simply move to another stack, but get hit by the team I work with being a JS team.

Sometimes I wonder if I should just go with PHP or Python or even Go, or Rust. With this new WASM thing popping up.

Tech is getting crazy, from WASM to LLM to WebWorker, Kubernetes and whatnot. Its simply too much to take in.

Collapse
 
danielbergholz profile image
Daniel Bergholz

Yep, for sure. There is a lot of decision fatigue in the tech industry. Personally, I decided that I do not want to work professionally with JS long-term, so I'm planning to fully migrate to an Elixir job in the future. I'm burned out on React, Next, and all of these Frankenstein frameworks, it's just too much for me

Collapse
 
raythurnevoid profile image
Ray Thurne Void • Edited

I've been working with svelte kit in the past two years and you can get a functioning project with a single "npm create svelte" command.

And the code you have to write to create a new page/api is pretty much the same as in your Ruby's example.

Plus the components use the same language of the server with some small additions to the html side, this fix two language issue you face when not implementing the UI in JS, at some point you have to add some custom script in the page and you find yourself do deal with two languages.

The alternative is to use something like Dart or Reason that doesn't require you to write JS because they are compiled to JS code, but they both are a downgrade from the simplicity and the flexibility that comes with JS/TS.

Collapse
 
danielbergholz profile image
Daniel Bergholz

That's good to know!
At this point I'm so burned out from JS, that I just want to run away from it to be honest

Collapse
 
codewander profile image
codewander • Edited

Great post. I agree with most of it. I am ironically moving in the opposite direction. (I have used almost every language you can think of in production including haskell)

(Also, I might recommend golang + elm SPA).

I love elixir. I have been working with it full time (backend only) for almost two years. The only downside that I know of with liveview is the lack of ready accessible headless UI component library. I am also hoping either roc or gleam eventually beat elixir, but right now it is a top lang + framework.

I am moving in the opposite direction for job interviews only. If more early stage startups used elixir, I would drop js in a second. (If you are looking to use elixir professionally, that will be an uphill battle currently since there are few job openings and they usually focus on experienced elixir devs)

Collapse
 
harsh2909 profile image
Harsh Agarwal

Great article
For the problems that you faced while using Rails, you might want to look at Ruby-lsp extension. It adds Intellisense and other things to the editor that Rails have been lacking until now.
It's still a bit rought but much better than not using anything.

Collapse
 
danielbergholz profile image
Daniel Bergholz

I tried it, but to me, it wasn't enough to have a good developer experience. Elixir LS fits my needs better currently

Collapse
 
marlonmarcello profile image
Marlon Ugocioni Marcello

Sounds like what you want is RedwoodJS. Heavily inspired by Ruby on Rails. Convention over configurations, generators, testing, component library, all configured and ready for ya with a single command. It's seriously underrated.

Collapse
 
danielbergholz profile image
Daniel Bergholz

Right now I would rather use Ruby on Rails. I hate that it’s mandatory to use GraphQL with Redwood. Just a lot of overengineering in general

Collapse
 
guledali profile image
guledali • Edited

Interesting post,

I'm about to build website for a client, initially I was looking on Next.js and Vercel but now I'm eyeing on Astro.build and vanilla javascript + web components

Not only is a lot simpler but support markdown with no additional npm install, it also ships no javascript.

Payload CMS is also good alternative, but I wanted something more simple.

If I was building an web application I probably would have used something in the vain of rails

Collapse
 
danielbergholz profile image
Daniel Bergholz

Very good approach! Astro for simple and static websites, and Rails for more complex backend stuff 🔥

Collapse
 
themuneebh profile image
Muneeb Hussain

Sorry, but based on my experience, your story doesn't end here. Once upon a time, I felt the same way. However, I came across something called "You Don't Know JS," which made me realize that I didn't know JS yet—where the actual problem lies. After exploring ecosystems of other languages, I returned to the JS/TS ecosystem. I believe the exposure I gained in this ecosystem is unparalleled, and I wouldn't find it in any other language. Restarting from scratch isn't something I can afford, and let's be practical—you just can't get rid of JavaScript. It's the most mature option available for working in the browser. Moreover, if you delve into it in-depth, it becomes the most suitable option for many use cases on the backend as well.

I'm not here to advocate for the JS/TS ecosystem, but mark my words, brother, you will come back one day.

Collapse
 
danielbergholz profile image
Daniel Bergholz

Thanks for sharing your experience! But after my burnout on JS, it's extremely unlikely I'll ever go back to it. Especially because with Phoenix Live View I can write all my frontend code in Elixir, zero JS required

Collapse
 
klebergueriero profile image
Kleber Nascimento Gueriero

OK, I actually didn't expect to see a post talking about Elixir coming from a frontend, specially talking about a journey coming from React.

It was, to say the least, interesting to know about your perspective in that journey.

Collapse
 
danielbergholz profile image
Daniel Bergholz

I think more React developers should give Elixir a try! It fits our mental model much better than a traditional OOP framework

Collapse
 
swapnilxi profile image
Swapnil Gupta

Really good Content as a react developer I can feel the same, it seems very breezy in start but you will find something is not alright, I wanted to switch to qwik, what is your thoughts?

Collapse
 
danielbergholz profile image
Daniel Bergholz

I completely gave up on the JS ecosystem at this point, to be honest. Every year we keep saying the same thing "This is the perfect framework! We can finally stop the framework wars!" and then this "perfect framework" gets replaced by another one in the next 6 months. It's a never-ending cycle

Collapse
 
brense profile image
Rense Bakker

Giving up on the entire JavaScript ecosystem sounds a bit dramatic tbh. It's not so bad if you ignore most of the hypes... React has been a pretty solid choice for me for the past 7 years and while I do keep a close eye on things like solidjs, I can also see that it is not mature enough that I would consider using it in anything except a personal hobby project. Just don't be scared to choose the mainstream for enterprise projects and keep the rebel attitude for personal projects or to further the ecosystem as a whole.

Collapse
 
alfredoneto profile image
Alfredo Neto • Edited

Nice post, man. Congrats!
I'll just address some of your points regarding RoR, and why i think all of your aforementioned issues regarding this matter just turn out to be something of a philosophy/mindset issue at the end of the day:

This will actually be useful to any tech stack, actually...

When coming from a different stack, naturally some things we're used to are just gonna be different(as you might've noticed). So, at least, in my opinion, you have to be as open to that new stack community standard practices and philosophies as you'd expect the new tech stack to be open to your needs and preferences, right? That means that, if you assume this open-minded stance, you and the new tech stack can meet halfway. I mean, of course you have no obligation to do so, you can go ahead and just hunt down the perfect stack for your needs, without much of a change in your own habits, as you did, and fortunately found one --which is great, good for you.

Watching one of your videos, i noticed you said that you were learning RoR only from Rails guides(the docs), right?

There's a important gotcha right here: The docs --at least in the RoR case-- are just enough to get you up and running with the technology, but i would recommend you to go a little bit further down into some other resources to learn from. The standard community best practices, the community philosophy and how to get around them are not in the docs. Some good resources would be: the books "Agile web development with Rails", from Sam Ruby, or "Rails Tutorial", from Michael Hartl. For Ruby itself, the books "Confident Ruby" , "Eloquent ruby" "Practical object oriented design with ruby" and "Ruby Science"(this one is from Thoughtbot) are great ones to get you up to speed with how the so-called "rubists" write their code, debug, think, etc..

So, having said all that, onto your points:

"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!"

-So, there it is, the point i made back there: Ruby is dinamically-typed language, and Rails is built on top of Ruby. Because it's a different language regarding types, there's also different ways, practices and habits to deal with this matter in the rails world. I can 100% guarantee that, if you had problems with "making a typo in a function and not finding out until the app is in production", something with how you go about developing in Rails is VERY WRONG. I mean, come on, doing something like this in any stack would be absurd, right? If any tech stack had this as an inherent issue, it shouldn't even be considered worthy of any attention to begin with. Do you really think rails devs suffer from issues like these on a daily basis? No.

"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. or deployment."

Again, it's still connected to my first point, with an open heart, you and the tech stack can meet halfway. The Rails community has a strong leaning towards tests in general. Because the idea about Rails philosophy from the get-go was joining the strong standard practices from Java/C# with the deligthful ruby syntax. If you just follow the implementation of the app built on the Agile web development with rails book, you'd immediately notice how much small/fast iterations doing unit/integration/system tests(which are extremelly simple to do using the built-in testing framework, Minitest along with fixtures) make up for a rapid and totally secure development, with no room left for "not finding out a typo until the app is in production" absurdity. It's ok to have preferences, though, but even you can admit that Typescript is just a huge band-aid on the whole Javascript mess. Furthermore, although Rails is a "batteries-included" framework, it doesn't mean i hasn't any room for external libs. There's a gem that implements static types in Rails called "Sorbet", if you're really hell bent on static types.

"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."

The magic in Rails is actually a Ruby trump card. If you read the books i recommended, you'll learn about Metaprogramming and DSL's in ruby, and you'd be able to create your own magic too :)
Moreover, you totally can look at the Rails source code from your IDE, actually, and don't forget Rails is an open source technology.

"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."

Well, as you might already know, everything is a tradeoff. Right from the Rails docs, you're informed about the "convention over configuration" philosophy, nobody is hiding anything here. You said yourself you were looking for a batteries-included, "convention over configuration" tech stack, This is an example of one. Rails is an opinionated framework. God forbid me going back to dozens of libs for each project, one for authentication, one for validation, one for the ORM, etc. Each javascript project is totally different from the other, there's no standard at all. Each and every Rails project you encounter will be more or less the same, overall. This is not to say that you can't bend Rails to your needs. It's actually possible(and easy) to do so, if you learn how Rails works under the hood.

Fun --and ironic-- fact: José Valim, the creator of Elixir, was a Rails team core member and even wrote a book called "Crafting Rails applications" that teach exactly that: adapting Rails to your needs.

About the frontend in Rails: At least for me, anything that is server-side rendered, integrated with the framework all-around, easy and fast to implement, capable of some impressive feats regarding complex interfaces, is more than enough(even htmx looks neat as hell).
I don't know why someone would move away from react to rails and expect the whole passing down props/state management/lifecycle hooks/global state madness that, i think, are solutions to problems they themselves created that didn't exist back in the day.

Anyways, just wanted to address your points. But im really glad you found a stack that suits your needs!

Collapse
 
danielbergholz profile image
Daniel Bergholz

Thank you for the super detailed feedback! I read it multiple times. I have many friends who use Ruby on Rails and they always tell me that if I forgot about the "react.js way" of doing things for a moment, I would quite enjoy Rails. But thankfully I was able to just keep thinking in react and adopt Elixir, which better fits my mental model of how everything is supposed to work.

Collapse
 
vladi160 profile image
vladi160

Thanks, nice article. Will try that sht Phoenix, which I read about for the last couple of years. Rails has autocomplete in VSCode and there is RubyMine by JetBrains

Collapse
 
mikaoelitiana profile image
Mika Andrianarijaona

Very interesting post, thank you! You did not mention deployment with Elixir, how was you experience on that. Did you find a Vercel-like solution or was it more complex?

Collapse
 
danielbergholz profile image
Daniel Bergholz

That’s my biggest struggle right now. It is a lot harder, you need to learn about docker, elixir releases etc. However I’m using Fly, which make this process a lot easier

Collapse
 
herman_verschooten profile image
Herman verschooten

I deploy using GH actions, no need for docker, just a simple elixir release that's copied to the server.

Collapse
 
restdbjones profile image
Jbee - codehooks.io

Great article, I think many developers will recognise that feeling of framework-fatigue that you describe so precisely.

Thanks!

Collapse
 
christian_go3 profile image
Christian GO

Interesting read, thanks for sharing!

Collapse
 
danielbergholz profile image
Daniel Bergholz

I'm glad you like it!

Collapse
 
blokche profile image
Guillaume DEBLOCK

I may give a try to Elixir.

Collapse
 
landsman_78 profile image
Michal Landsman

As a developer with 15 years in the game, I can not more agree.
It's a mess. No MVC, bad developer experience without strict rules.

Collapse
 
ryands17 profile image
Ryan Dsouza

Could you share the reason to move from Next and Remix? What issues did you face exactly?

Collapse
 
danielbergholz profile image
Daniel Bergholz

I actually had 0 reasons to do this switch, I only did it because of my day job 😅

Collapse
 
lucaschitolina profile image
Lucas Chitolina

This is a huge-quality post, you described everything perfectly. Congratulations again!

Collapse
 
danielbergholz profile image
Daniel Bergholz

Thank you!

Collapse
 
codemeisterav profile image
avelops

Great read!

Collapse
 
samiralibabic profile image
Samir Alibabic

Great post and very interesting journey! 👏🙌

I would add lit and web components to the soup.

Collapse
 
alveek profile image
Alveek

Thanks for sharing!
Definitely going to check elixir!

Collapse
 
tjhunkininhance profile image
tjhunkin-inhance

You lost out by ditching Laravel for small syntax issues :) Livewire 3 is also pretty neat.

Collapse
 
danielbergholz profile image
Daniel Bergholz

It's just my personal preference, I could change my mind in the future

Collapse
 
pppdns profile image
Denes Papp • Edited

it's not just small syntax issues. PHP is a terribly designed language. It's verbose, far from being type safe, missing most of the type definition syntaxes that other modern languages have had for ages, and it's slow and inconsistent.

This is an old article and many issues have been fixed in version 7, but many are still there
eev.ee/blog/2012/04/09/php-a-fract...

Even basic features are missing. You have to use ugly workarounds like PHPDoc blocks for them. Type inference only supports very basic types, nothing like Typescript or any other modern language.

Laravel is awesome, it's a shame it is using PHP

Collapse
 
tjhunkin profile image
tjhunkin

Cool man

Collapse
 
christianpaez profile image
Christian Paez

Very good post, thanks!

Collapse
 
leonemac profile image
Leonardo Machado

Read the entire article thinking "wow, that is great, I wonder if the author have any more content" then I realized IT'S FUCKING BERG FROM YOUTUBE LMAO

Collapse
 
danielbergholz profile image
Daniel Bergholz • Edited

YOOOO IT'S MEEEEE, NOW IN ENGLISH 🤘
Thanks for the awesome comment!

Collapse
 
stoddabr profile image
stoddabr

Any reason you didn't consider some go/rust based systems? Could you not find any that were mature enough, maybe?

Collapse
 
danielbergholz profile image
Daniel Bergholz • Edited

Good question! I did consider trying golang, however, what annoyed me a little bit was the "fragmented" ecosystem, similar to JavaScript. There isn't a Ruby on Rails for it yet, just a bunch of libraries that I would have to "glue" together.

If someone builds a framework that includes an ORM, routing, authentication, testing, modern frontend and all the "batteries included" philosophy, then I'll definitely give it a chance!

Oh, and after being "bit" by the Functional Programming virus, I can no longer see the OOP languages in the same way

Collapse
 
rafaelnacle profile image
Rafael

Nice post! I've also messed with Elixir and it is really cool!

Collapse
 
radandevist profile image
Andrianarisoa Daniel

Have you tried AdonisJs? It's like Laravel but for Node.

Collapse
 
danielbergholz profile image
Daniel Bergholz

For sure! I used Adonis for 2 projects, and I loved it! It's the closest thing we have to a Ruby on Rails for JavaScript. The only reason I stopped using it is because the community around it (unfortunately) is very small. So for example, to release a new version the core team takes multiple years.

But if you don't want to leave the JS ecosystem, it's a very good choice!

Collapse
 
chris_lu_f1a9fd9cfc9 profile image
Chris L*****u • Edited

Great post, exceptional work, thank you. (except the Java , C# comments 😊I am old school so these languages have earned my respect )

Collapse
 
shazz profile image
shazz

Thank you ... very nice observations. Convinced me to take up Elixir and Phoenix.

Collapse
 
dvsource1 profile image
Viraj Kaushalye

loved the writing style 🥹

Collapse
 
chiroro_jr profile image
Dennis

This as an amazing read. I enjoy all of it. Great opinions on the madness going on in the JavaScript ecosystem.

Collapse
 
juozasm profile image
juozasm • Edited

Hey, nice post, but for me react is best option.if you will want to extend from web app to mobile, then you will not be able share buisness logic with React Native

Collapse
 
danielbergholz profile image
Daniel Bergholz

Phoenix has LiveView for the web and LiveView Native for mobile 👀

Collapse
 
guilhermeomt profile image
Guilherme Tavares

What a fantastic post! I also gave up on the JavaScript ecosystem as my main stack for the same reasons you described. I've spent a ton of money on front-end courses, which I don't regret because I've gained valuable skills.
However, I recently discovered my preferred technology stack: C# / .NET and Dart / Flutter. I realize it might seem unusual to opt for both web backend and mobile dev technologies, but I believe this versatility will increase my chances of landing a job in either field.

Looking forward to reading more of your articles!

Collapse
 
giullianosep profile image
Giulliano Ferreira

Dude, I watched your video on Youtube talking about this because I had kind of a similar experience. I've always loved Python and Django, but never had the opportunity to use it professionally, I ended up working with C# and .NET (by the way, you should give it a try).

I have been working with SAP and ABAP for 10 years but I hated it from day one and I've been trying to leave this shit for a long time now, so I decided to study something new and started studying Javascript. I felt overwhelmed by the amount of different libraries and frameworks that exist to solve the exact same problem and, like you said in your Youtube video, having options is good, but too many options can get in your way. So I kind of gave up on it and now I'm slowly learning Rails and Django, but I'm also very interested in Elixir.

I agree with most of your points, but let me tell you, there’s no perfect solution for everything and there's always a feature that sometimes I think "man, I'd really love if Django had that awesome Rails feature".

Collapse
 
dave profile image
Dave

That is a great post. I've been on the same journey until I settled with SvelteKit. The challenges with using something like Elixir, in my opinion, are two:

  1. UI frameworks: I've missed a lot of them since I moved off from React. When using VanillaJS or a similar framework, it's challenging to find a comprehensive UI library. You could opt for DaisyUI, but for elements requiring complex logic, you'll need to develop them from scratch.
  2. Serverless: I'm not sure about running Phoenix in a serverless environment. My main issue is that I don't want to maintain a dedicated server. Fly.io announced Flame not long ago, maybe that could help I don't know.
Collapse
 
smujaddid profile image
Sibghatullah Mujaddid

Finally I found an interesting article to read.

Definitely I have similar feel about Js. I get the burnout just from my short 3 years experience of its ecosystem. I am a Laravel user which I consider more complete and simpler than similar frameworks in Js ecosystem. I don't care if it is an "Old boring" tech stack, the only matter to me is its simplicity.

Now, I started learning Elixir/Phoenix since last week. I believe this is best the alternative of Laravel that I was looking for. Maybe doing some project while learning all about both the language and the framework. Let's see.

Another ecosystem I want to dive into is Dart. I worked once on a Flutter project, and it was a satisfying experience to work with. I love Dart as a language: simple, familiar and easy to learn. It also has complete tool chain and included by default, no need to learn every other tool chain just like in Js ecosystem.

Collapse
 
jayeshhire profile image
JayeshHire

Brother, I am a beginner developer and currently learning javascript as well as trying to understand the node ecosystem. After reading this blog you have somehow put me into a dilemma.
Shall I continue this journey or do you have some better suggestions.

Collapse
 
kasvith profile image
Kasun Vithanage

Im a fan of elixir, not a fan of LiveView

it looks simple, but get extremely complicated when you try to do something...often ending with terrible JS hacks