ElixirConf 2018 - Keynote - Chris McCord

If you didn't provide constraints (node/react), I would use the following. Please note, this is highly opinionated, so nothing to get offended or upset about. I like to keep my stack simple: A. Simple static sites: - Jekyll B. Medium complexity, CRUD applications: - Phoenix/Elixir - Coffeescript Note: With the latest version of Phoenix, you absolutely don't any JS frontends at all. Watch they keynote presentation for the liveview demo: [this video] C. Complex Web applications: - Phoenix/Elixir - GraphQL/Absinthe - VueJs + Vuex + Coffeescript Developing with Phoenix/Elixir is so much better than any of the node frameworks in the ecosystem - this has consistently been my experience. So, give it a shot if you can.

If you are feeling a bit adventurous and open-minded as you begin this venture, I would highly suggest looking into Elixir and Phoenix, especially since you are asking for "...best bang for the buck". In fact, the 1.8.0 release for Elixir was just announced earlier today here: [link] ( [link] ) What makes Phoenix great is that, not only is it blazing fast, but the framework serves as more of a web interface to your application as oppose to "taking over" your application, like with other major frameworks. Moreover, you get the full power of Erlang and OTP as well. I will have to say that some things are a little rough still, like deploying your application. This process is not as smooth as what you would experience with a Rails or Django app, but it will definitely get better over time. One of the features of Phoenix that is also really exciting is LiveView. If you have some time, definitely check out Chris McCord's 2018 keynote: [this video] There are a lot of great books and resources to explore. I listed a few below: [link] [link] [link] (just released) [link] [link] With regards to Python, I cannot give too much recommendation as I have experience in Ruby/Rails and Elixir/Phoenix primarily. However, if you really want to begin building, stick with Python, since you already have experience with that language, and look into a popular framework, like Django or Flask.

Yes, that was my inspiration! Chris gave a great talk about it at ElixirConf is anyone is interested in watching: [this video] Some differences compared to LiveView: - Type-checking: there are extensive JSX typings ( [link] ) that ensure you're attaching event handlers with the correct signatures, specifying supported props, using valid HTML tags and attributes, etc. Static-typing guarantees are one of my big priorities. - I'm not sure if LiveView intends to support nested components like React does. Having the ability to split up complex pages into components that you can nest and reuse (with mostly one-way data flow) is a key part of maintainability. I wanted to maintain a very familiar React interface, so you can pick up Purview quickly if you're comfortable with React.

I can't give a deep comparison since I haven't done anything too deep with LiveView (yet!) but I would encourage you to watch the keynotes on LiveView[1][2] if you're really interested. I have spent the last few years working with React / Redux on a big SPA and I believe the entire thing could easily be supported by LiveView; we don't do anything fancy, its basically just a bunch of CRUD based pages. Another shallow comparison is that LiveView isn't meant to compete with modern progressive SPAs. While it can update the DOM with data from the server and is very good at doing that, it has limitations such as no offline support. Chris (the speaker in the videos) also notes that if your clients require very good latency or a very complex UI (think Google Sheets) then a JS framework will probably better suit your needs. However, if you're building out a majority of websites (CRUD type pages) that a lot of us web developers do, my personal opinion is that LiveView will be able to everything needed. [1] Announcing LiveView @ ElixirConf 2018 - [this video] [2] LiveView Update @ ElixirConf 2019 - [link]

> If I had to guess, I would guess that React will still be around in 5 years, but I'm not sure web components will. I agree, and this is why I use React (or rather Preact) for both apps and interactive elements on the page. The big caveat is that in practice it's really easy to end up with a React project that is much more difficult to maintain compared to a monolithic framework (Ember, Angular, Vue, even), because of all the other crap that might be used to take care of all the stuff React doesn't do. For example, I recently took on a React project that used a whole bunch of other packages for state management, routing, etc., and a number of those packages were no longer supported (or outright compromised). While it's nice that React is still React, a lot of these other packages are tightly woven into the whole 'fabric' (react-swipeable-redux-router type stuff). For my part, when I start a React project I try to minimize these problems by generally avoiding react-specific packages. So instead of react-router (which had its share of non-backwards-compatible updates), I'll just use page.js for routing. In some cases I might use the reactified version (Redux comes to mind, but I avoid that most of the time for smaller stuff). This still isn't a panacea, and as a result I've been moving more and more stuff to a more 'vanilla' Railsy backend (Elixir/Phoenix, specifically). While the ecosystem does seem to be stabilizing a bit, it's still insane, and thankfully there are or will