Builtwith says Devtalk is built with Rails. Was there a reason Phoenix wasn’t used initially? Not necessarily LV but just Elixir / Phoenix in general.
Could have been a cool opportunity to build a real world app with Phoenix and even open source it. Sort of like what https://dev.to did (another similar site built with Rails).
I won’t speak for AstonJ regarding the why, but…
Devtalk is currently a customized instance of Discourse, if that offers any insight.
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…
(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? 
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.
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.
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.
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
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.
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.
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.
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.
This is an excellent breakdown, thank you for writing it! However, I think we need to settle on the main use case for LiveView here which is not to go head on with JS attempting to replace it, but rather provide a first step into having interactive UIs, similar to what Rails initially had with RJS. The fact that LV provides hooks by leveraging JS libs that already exist can already get you to a good middle ground, without that I don’t think there would even be a discussion.
I agree that it would be madness to even consider LiveView, which is not even 1.0 yet, on any mid to large size projects, but still think it is much more viable when boostraping an idea with a few developers. This is quite uncharted territory, though, as you mentioned, most UI devs know JS and would be very uncomfortable with the idea of learning a functional programming like Elixir, so the path of least resistance would be to just stick with the status quo, as it is with any other new idea.
What worries me a bit is that we are already so far out in web development that any app that wants to compete in the space needs to be really polished, and the tools to get that polish are all deeply ingrained in the JS ecosystem, so competing in this space seems a bit futile. My bet is that LV will really shine in development time for apps that will take full advantage of all the connectivity benefits that Elixir provides, we just haven’t seen much of this new class of apps yet.
I was going to jump in to mention your second point.
I might not be a UI dev, but paired with material-ui, semantic-ui-react, blueprintjs, or AntD I feel extremely productive, and can build pretty compelling UIs. And feel like assembling Lego!
Now LiveView has none of that, I am left reinventing alot, and having to do a bunch of CSS to make it look good. All of which comes out of the box in the toolkits mentioned above.
People have had success with CSS only ui frameworks in liveview…but not sure that really cuts it…
Surface and component library ideas for LiveView would help, but who is gonna do all that? All the UI people are busy writing JS + CSS 
What would a LiveView “components” library look like? Would it just be a thin wrapper over some CSS like the Surface framework? Or something that compiles down to HTML+CSS in the manner of the excellent elm-ui package for elm?
Take a look at https://blueprintjs.com/
Replace ‘React-based UI toolkit’, with LiveView UI Toolkit.
CSS is a large part of it…and the interactive bits are all JS. So I imagine a LiveView UI toolkit’ would be pretty much the same with less or no JS? EDIT: So yea, Surface is the right idea - but still writing CSS or at least manipulating CSS…a proper web-component either native or with something like React - can abstract away pretty much all the internals, leaving you with some prop based API that does all the class toggling or whatever as an implementation detail
The elm UI package describes the result of such a toolkit’
This library is a complete alternative to HTML and CSS. Basically you can just write your app using this library and (mostly) never have to think about HTML and CSS again.
I agree with you about the rest, but I don’t think it’s a small/large project thing. Many large projects do not need offline support, nor app support, and are not SPA, like online shopping malls. Conversely, lots of small projects benefit from offline support, including blogs.
Thanks to the comments in this thread (as well as the one on Devtalk) along with being able to use TypeScript instead of JS (the stubborn part of me wants to avoid ‘js’ at all costs - even if by just its name!) I’ve decided to give SPAs another look.
After reading the comments in this thread, Svelte looks really promising and appears to be gaining in popularity the most right now.
In m opinion, LiveView needs two major things to really be viable.
"Live View Components"
A dedicated “single file component” consisting of language blocks. You might have an HTML block (eex), CSS (scss), a script block (JS that tapped into hooks), and an Elixir block (the LiveView code we’re familiar with). The combination of these blocks into a single file makes things considerably more maintainable, in my experience with Vue’s Single File Components (SFC). I think someone is already attempting to do this in the spirit of Vue. It is important that on compile, these blocks get intelligently broken out into bundled files and loaded when applicable. As a simply example, the “about page” component’s CSS should load only when the user navigates to that page, but this concept has been used for extremely proficient page loads (extreme CSS / above the fold CSS, etc.).
Decoupled JS library
The front-end code to LiveView should be broken into two distinct parts. This would open up a world of hybrid apps where LiveView could live side by side SPA logic. Interoperability would help teams integrate LiveView in an iterative way as opposed to a mutually exclusive way (as it feels now).
The communication library between the browser and the Elixir server. There should be NO presentation layer logic. Not just hooks, but full-blown event system. This could be layered with “reactivity” and caching libraries.
A basic (opinionated) presentation layer. Essentially what we have now, but it can swapped out for Vue, React, Stencil, something custom.
With the two things above, I think a lot of the pieces would fall into place and other aspects would resolve themselves.
Hooks aren’t sufficient, IMO. LiveView needs to be fully agnostic / unopinionated to the presentation layer; with an optional lightweight UI library. See my other answer on what this would enable.
we’ve started a project called LiveData, to explore these ideas. It exposes server side state in a nice API to be consumed via React or whatever. Join us on slack, livedata
© Copyright Elixir Forum | Terms | Privacy & Cookies
