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