Is JavaScript framework necessary for frontend?

Another solution is the new framework GitHub - hotwired/stimulus: A modest JavaScript framework for the HTML you already have · GitHub from Basecamp Team, a way to organize what they call javascript sprinkles.

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.

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.

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.

Not every business is a startup, so priorities can shift considerably depending on the situation.

1. Startups can’t afford any delays getting to market so writing something from scratch is out of the question - and often they’ll re-write a lot of it anyway once the business proves viable and they have a better idea of what they really need (example: NoRedInk started with a React-based solution and then proceeded expand and replace with Elm). SmartDraw already had a desktop based flagship product that was sustaining the business for the time being but they wanted to extend their reach with a web-based version. So their emphasis was on (a) getting it right “the first time”, i.e. having a feature-comparable web-product that wouldn’t tarnish the reputation of the existing product (and the company) and (b) having a web-product that can evolve alongside the desktop-product without costly technical divergence.
2. Established businesses do not like change for change sake - to them the churn in the JavaScript ecosystem seems absolutely insane - when do you get the “real work” done if you constantly have to learn the next “tool du jour”. You mention lodash, well before that underscore was king, “which was doing it wrong” so other people moved on to ramdajs - and the entire JavaScript ecosystem is like that; npm scripts, grunt, then gulp, screw it, webpack is way better, what brunch you say? Whatever you adopt today may be an unsupported tomorrow (even if it is open sourced by giants like Google, Facebook etc. - and they have they own agenda anyway (which they are entitled to as they are paying for it)). So one way to create stability is by building your own stuff - which tends to be much slower (and expensive - at least in the short run).

Agree with Andre—honestly Elm is really cool and all but it’s not in any way in the same size has Elixir (and Elixir isn’t that big either). Elixir has had a handful of conferences and like four books on it and a big forum like this, not to mention a lot of adoption from the Rails crowd. Elm has just one book which isn’t finished and the language itself it still changing and maturing. Elm got lucky with NoRedInk and they’ll definitely help prove it’s a real language to work with though, I am rooting for them.

That said, if I were going to write a business (not a side project for fun) that needed a JS frontend, I wouldn’t go with Elm. There’s just way less help and resources for it out there. Honestly, JS isn’t that bad any more (I’ve actually never had a problem with it, but meh) and there’s a good amount of frameworks/libraries to help you out as well as type checking stuff like Flow or TypeScript.

And yes, this forum runs on Ember!

Also, @StefanHoutzager that link is interesting until I read this part:

It took us a year or more to write these libraries. With these in place we set about writing the app.

This is ridiculous. No way any sane person spends a year writing their own versions of libraries before starting their app. Learn the JS ecosystem and what is good vs what isn’t (for example, lodash’s padStart vs left-pad)—plenty of successful apps millions use everyday rely on the libraries they said were bad and had to modify to make “more robust”. Shrug. Sorry, just seems really stupid to me.

You may also want to look at Elm-lang.org for the frontend, it plays really well with Elixir and Phoenix, it is a functional programming language that compiles to Javascript and is a lot quicker that a lot of the existing JS frameworks out there. You can use it with Material Design too. Josh at Daily Drip has a few episodes that show you how to integrate the two. You are going to end up with a lot less errors too as Elm catches them at compile time unlike JS giving you all the cryptic messages. Chris McCord talks about using Elm and Phoenix here https://www.youtube.com/watch?v=XJ9ckqCMiKk

This one is worth a read also https://blog.smartdraw.com/how-we-wrote-a-desktop-quality-app-in-javascript-that-avoids-framework-hell/

This website (elixir forum) is and Ember app. : )

Thank you, @sheriffderek. This is a good read.