I won’t speak for AstonJ regarding the why, but…
Devtalk is currently a customized instance of Discourse, if that offers any insight.
Ted
AstonJ
There were a few Nick 
Originally Devtalk was just going to be a forum, and as @Ted mentioned we decided to use Discourse (it’s the best forum platform out there right now). We were aiming for a February launch and were actually a little ahead of schedule so decided to create a dark theme, and then an OLED black theme… and then have Retina and standard versions of each 
This however pushed us into mid March. We had also been receiving some amazing feedback and that inspired us to become more than just a forum. Since we were already using Discourse on the forum and because of our tight integration with it, it made sense to stick with Rails for the rest of the site.
It took something like 10 weeks to design and build the non-forum parts (i.e the homepage and portals) and using Rails made that a lot easier not just because of our integration with Discourse but also because I’ve worked on another portal-based site which was also made in Rails (and we were going to be borrowing many of its ideas). So it was easier to stick to Rails if we wanted to launch as quickly as possible (which we did because we had arranged several giveaways that were meant to start in Feb and PragProg needed their errata forum up to coincide with the re-build of their own site - plus we just wanted to get it up asap as I feel that is the best way to ascertain the direction of a site, i.e by real world use).
So time constraints and the fact that we were using Discourse were the biggest reasons behind using Rails. There were however some other reasons too…
- Rails is very much suited to that kind of site
- LiveView hasn’t reached maturity yet
- ‘Before and afters’ can be powerful in marketing a piece of tech
- I haven’t finished learning Phoenix yet (in part because of (2))
(1) I actually think it would have been a bit of a waste making the site (as it is) in Phoenix; it wouldn’t have been much of a showcase because there’s nothing really technically new or outstanding. If we want to show off Elixir then I really don’t think it would have done a good job other than get it some initial exposure (which it is getting anyway via the threads/top portals list). If anything, people might have focused on that and pointed out that it’s nothing really groundbreaking and could have just been made in Rails probably easier and quicker, and they would have been right.
For Rails I think it’s a pretty decent showcase. Turbolinks makes it fast, especially when a cache kicks in, and that aspect of Rails is pretty cool in itself (when a cached page is served it sees a reduction of up to 75% of cpu resources used per request (pre-cached they are typical of similar pages being served in other languages like PHP) - Rails caching is pretty amazing, particularly impressive given most of it is practically automatic).
(2) and (3) I think Erlang/Elixir/Phoenix offers us the opportunity to build the kind of apps that we just can’t build in other tech like we can in the BEAM world. When I think about a version of Devtalk built in Phoenix, I picture something a lot more ambitious! 
Therefore being able to compare a Rails site and a Phoenix version in this manner is highly beneficial - because you’re better able to show off the stuff that makes Phoenix ‘better’.
(4) And finally, I haven’t finished learning Phoenix yet. I know some people like to learn on the job but I prefer to learn as much as I feel I need to beforehand. Coupled with time-constraints and that I’d prefer to have taken a different (more ambitious) direction with Phoenix meant the fastest route with Rails was the only feasible choice. That’s fine though, as like I mentioned above, it gives us the opportunity to say look, this is what we had in Rails and this is what we’ve come up with in Phoenix, while at the same time ascertain the direction in which we want to take the project.
I agree, although as mentioned above I feel it should be something that shows off Phoenix and isn’t just a typical Rails type site on Phoenix. Wouldn’t you agree? 
3
cnck1387
Yeah.
Although dev.to in itself feels lightning fast despite being a mostly server rendered Rails app. It would be neat to say you can do the same in Phoenix without LV, and perhaps even with less code.
I don’t know about you but most dev.to posts load as close to instant as you can ask for (feels like 200ms or less to be painted in the browser from end to end), but DevTalk feels closer to 1-2 seconds to load a page to the point where I can read the content of the post.
3
dorgan
Dev.to prefetches the posts when you hover the link, there is a time window of about 300ms between hover and click, and thats usually enough to request and receive the next page, thats where most of their perceived speed comes from.
I think turbolinks, unpoly and pjax can do this, maybe it wouldnt be too hard to do with a modified live routing in liveview.
2
cnck1387
Ah nice, I never looked at the code base in depth.
I also noticed that I ping 12ms to dev.to but 100ms to DevTalk so that likely accounts for something too.
2
AstonJ
I thought they were just putting the most frequently accessed stuff in memory (similar to what Stack Overflow does - they blogged about it a few years ago iirc). However, neat as it is it’s not a million miles from TurboLinks + Rails caching / memcached, in fact I was actually going to use them both as an example of ‘basically Rails’. Both dev.to and Devtalk (frontpage/portals) regardless of how quick they load, are more or less static - there’s no real dynamism or real-time features which is something Phoenix can excel at.
I wouldn’t really want us say ‘hey we can do this in Phoenix as well’, but rather ‘hey look at what we can do in Phoenix 
’.
I think the SmartLogic crew touched on this when they said they felt they were often disappointed that there wasn’t enough drive in the community to displace Rails, and while I don’t think we need to do that (let’s just let Rails continue doing what it does best) we just need to show that you can actually do next-level stuff in the BEAM world essentially carving out our own place in the world.
Unfortunately that is because the forum is an Ember app, so whenever you click through to a thread from the home/frontpage you are essentially having to load a SPA. I have mentioned a few times in the Members only sections over there that I dislike the disconnect between the Devtalk frontpage/portals and the forum, and it’s why I am evaluating converting everything to Phoenix.
What concerns me is time. Creating a forum or a community platform from scratch is very time consuming and a lot of hard work. When Xenforo launched it was three years before I felt it was ready for a live site - and Xenforo was made by two devs who were two of the three main devs working in industry standard forum platform before it, vBulletin. When Discourse launched it was 3 years before I felt it was ready for a live site as well, and Discourse was made by an experienced team as well. Luckily we have a lot of the design already complete, but still, it would be a lot of work..
I ping in about 25ms to Devtalk but yes Dev.to is half that. I guess they have some pretty elaborate(/expensive) hosting set-up (let’s not forget they have received over $1,000,000 in funding - we are totally bootstrapped )
Edit: actually it’s closer to $12M
3
bjunc
Like most everything, incentives/constraints will heavily influence your decision. If you’re looking for a Pareto Principle answer, I’d say:
-
If you (or your team) have already gone through the major hassle of learning the JS/UI ecosystem, and it’s a medium+ sized project (or will be), then it’s better to leverage that knowledge.
-
If you (or the team) are heavy in backend knowledge, and it’s a small project (eg. marketing site with minor API back-and-forth), you could get away with LiveView.
I have extensive experience in UI work, and I can say there are many aspects of LiveView that fall short of a modern SSR/SPA JS app. I would love to see JS put back into the territory of light scripting for which it was intended, but LiveView is not the answer to that (unfortunately). The DX of UI work is a major barrier to entry, but once you have it set up, it is extremely powerful.
That said, sockets, GraphQL and WebAssembly make it very easy to make the UI as “dumb” as possible; with any major UX decisions handled via API/RPC, and heavy computation via WebAssembly. I see this as attacking JS from both ends, eventually squeezing JS back to light scripting. We just aren’t far enough along in this to abandon the SPA concept.
Just my 2c.
2
GunnarPDX
IMO a really underrated aspect of SPAs is that you can pick up dedicated front-end devs easily and with minimal friction, even if you just need a freelancer here and there to help out with delivering features, and you can do so without handing over the backend source code. It’s probably not super important for the indie hacker, but from a business perspective, it’s definitely worth considering.
9
pedromtavares
Would you mind going into those aspects a bit? I think it would be interesting to dissect the line where LiveView isn’t worth it anymore, and how much of the web would fall into that category. If you already have a front-end team then you are obviously going to leverage that knowledge, but small teams with limited scope and budget could definitely harness LV effectively, and I think these may be the majority out there when it comes to new projects.
2
bjunc
I think this topic really could be broken out into a dozen smaller pros/cons comparisons. It would be beneficial for the community, as the topic of full-stack Elixir comes up quite often. To really answer your question, it’d be worthy of a detailed blog post (I might be volunteering myself in writing this). However, if you have a specific question / sub-topic, I’d be happy to answer it here.
That said, here are 6 reasons that come to mind to continue reaching for JS in the UI:
-
JS devs tend to also be HTML/CSS devs with more UI experience than Elixir devs. It’s not just a language preference, it’s also domain experience. Do you know when to reach for flex-box vs grid? JS devs are more likely to have a better understanding of UX, experience in the many browser quirks, and an “eye” for UI. Also, UI devs tend to be cheaper than Elixir devs. The economics of specialization and comparative advantage are at play.
-
Plenty of turn-key UI libraries. For instance, Material components exist for Vue, React, etc.. I keep seeing these really primitive LiveView UIs with basic CSS. That’s just not what a modern app looks like. Are we going to build a multi-select, token dropdown menu that support slots, is accessible, and mobile friendly in LiveView? Yes? How about the other 20+ common Material UI components? What about charts? Are we going to build a LiveView library with parity to D3.js? What about animation libraries like GreenSock? Are we going to “stream” position updates, or have lightweight UI libs that handle transitions based on configs sent from LiveView? Is that even worth it?
-
UI components. For instance, Vue single-file-components (SFC) are a HUGE benefit in my experience. Keeping your script, CSS, and HTML together in the same file makes maintenance really useful. Vue will automatically scope your CSS to prevent accidental specificity conflicts. Transpilers like SCSS are easy as well. The modules will live update in the UI on a per-module basis. Meaning, without a full page refresh you get just the module that swaps out. Super useful on big apps that have long compile times.
-
Repurpose the UI for mobile. Many apps are built in React Native (or similar); often built by the same team that is building the web UI. Elixir doesn’t have an option for that.
-
Offline support / service workers.
-
Centralization / decentralization. By offloading rendering work to the browser, we decentralize computation resources. With LiveView, you’re now concentrating all that work on the servers. Servers are pretty cheap, but the client’s browser is free.
Hope that helps. I am very optimistic that JS is being attacked from multiple angles (LiveView, WebAssembly, etc.). However, we’re not doing ourselves any favors by comparing LiveView to narrow JS use-cases and ignoring the many aspects of modern JS. Like I said, for smaller / marketing projects, blogs, etc., LiveView could definitely work. For larger projects (or ones that could grow into larger projects), I don’t yet see LiveView as a viable replacement.
17