Is JavaScript framework necessary for frontend?

Not using technologies you like in projects where you can choose is a sin(nacho libre).
If we don’t use Phoenix and Elm who will?

I would use a JS framework for any project for the following reasons:

  1. Evade JS as much as possible (in case of Elm).
  2. Future proof the project in case the client wants to add “bling” the next day.
  3. Avoid JS as much as possible.

My non-expert opinion. :slight_smile:

One more nitpick about that “we avoided framework hell!!” post, precalculating array sizes is actually slower than not doing it. Why? Modern JS engines already cache it for you, so you can just write a regular loop and not worry about it. Cool, mostly unknown tip.

2 Likes

Hello to all!

A lot of people in the world have done, are doing and will do in the future multi-page applications on Ruby on Rails, Phoenix, Express, Django, Flask, ASP.NET etc. This is a fairly stable approach for medium and serious applications with advanced business logic.

But developers constantly have a headache when try organizing a big-app for thin client. Collisions between the scripts and callback-hell, causes people to seek refuge in the new hyped “frameworks”, But they require a more complex organization of the application code and generate a new cluster of problems inherent in the thick client.

At the moment, there is an excellent javascript framework Normas.js for creating a thin-client without a headache, which is successfully used in production: https://github.com/evrone/normas Do not abandon the server rendering in 202x, it’s a great approach for burst creating an MVP or full release.

Another solution is the new framework https://github.com/stimulusjs/stimulus from Basecamp Team, a way to organize what they call javascript sprinkles.

2 Likes