Keeping brunch is honestly a better idea. It will compress, minimize, and optimize the little javascript that you may have, as well as doing the same with your CSS and potentially more.
Just be careful with your long term investment in jQuery - it has a dangerous habit of discouraging acquisition of âproperâ JavaScript skills (much in the same way many JS frameworks discourage acquisition of âproperâ web application (solution) design skills 
).
You Might Not Need jQuery
You Donât Need jQuery (anymore)
5 Reasons Why You Need To Learn To Use JavaScript Before jQuery | kaidez
So you know jQuery. Now what? | Remy Sharp
jQuery considered harmful | Lea Verou
2 Likes
I donât buy this. People that hate on jQuery forget that just a few years ago it was the cure to the madness that were different browser standards and APIs. It became a victim of its own success as browsers started to converge[1]. Obviously, you should know a bit of JS before using it (though not too much if you just want a basic site), but itâs definitely worth it and it may save Red a lot of trouble.
jQuery doesnât discourage proper JS skills any more than Phoenix discourages OTP and Elixir knowledge or Rails does with Ruby knowledge. Itâs not jQueryâs fault that people too lazy to learn JS call themselves JS devs when all they know is jQuery 
That said, your last link is great and there are smaller alternatives like Zepto and fetch (for Ajax) that do the job well. I just donât like to see jQuery being bullied for the wrong reasons!
[1] Still useful: https://mobile.twitter.com/jeresig/status/590199945174634497
4 Likes
Iâm partial to React, but if youâre looking for more of a framework, I suggest Ember. The performance improvements in their somewhat-recent 2.0 release have put it back on the map.
I really like this thread. Iâve learnt a lot from it. Thank you, everyone.
1 Like
Why is there no mention or recommendation of Elm?
3 Likes
Here ya go:
1 Like
If a person is looking to learn a framework to use in commercial projects Elm is not exactly at the top of the list 
Hey. NodeJS developer here.
Not necessary. Especially a website similar to Hacker News. You can just use plain Elixir/Phoenix (server rendered). This will also helps easier indexing by search engine.
In case you want an easy JS framework/library. I suggest React + MobX. I came from Angular, React/Redux, and I feel React + MobX has a nice balance between those two.
As others have suggested. Keep the brunch for now. Itâll come in handy
Care to share some criticism on elm? Itâs maybe not ripe enough?
There is little demand for elm work, so if a person is looking to learn 1 framework and be able to make a living programming using it Elm is not an ideal candidate.
At the moment, you could say the same about Elixir as well. We are all generally here because weâre looking forward.
5 Likes
I think you should try Ember when you get to the point where you need more than Phoenix can offer. https://medium.com/peep-stack/building-a-performant-web-app-with-ember-fastboot-and-phoenix-part-1-fa1241654308#.lel3i8ekv
3 Likes
There is fairly strong uptake of Elixir compared to Elm you have places like DockYard and Erlang solutions and Plataformatec and large projects like bet365 and quite a few others using it. A good chunk of Ruby consulting shops is looking into adopting it. You have a very compelling value proposition with Elixir/Phoenix. I am not saying there will not be more production deployments of Elm but again if you need to make a living right now only knowing Elm would be really problematic vs you can actually get a day job doing Elixir.
2 Likes
Thank you, @sheriffderek. This is a good read.
This website (elixir forum) is and Ember app. : )
This one is worth a read also https://blog.smartdraw.com/how-we-wrote-a-desktop-quality-app-in-javascript-that-avoids-framework-hell/
3 Likes
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
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.
1 Like
Not every business is a startup, so priorities can shift considerably depending on the situation.
- 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.
- 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).
3 Likes
