I think LiveView is good. It gives devs another option. How much it fits one’s particular use-case will vary, but it is definitely an improvement for some use-cases and is an exciting step from a server-side tech standpoint.
As for this thread, I think while it can be informative, the real conversations come when you’re actually building the app.
That was a long nap 
I believe this is too restrictive and partially missing the point of Live View. While you could use Live View to build a game, and that would make it chatty and what else, most of the use cases for Live View are for interactions where you would need to talk to the server anyway. Autocomplete, form validation, buttons that submit, receiving live updates, etc. And if you use Live View for those use cases, it is likely going to be less chatty and more efficient than hand-written ones. Many clients written by hand settle on a AJAX plus well-structured JSON APIs. On the other hand, Live View work on WebSockets using indexes for updates, while computing diffs to avoid sending extra data. Plus a more efficient serialization format is coming soon. On the server side, there is more memory usage but likely decreased latency, as you don’t need to authenticate and fetch database records on each request.
So I would argue that if the answer to the question “is this going to the server?” is a yes, then LiveView is likely a good fit (and probably more efficient than if you were to implement it yourself unless you are willing to put more development time) and that is a wider domain than the obvious internal apps at corporate networks.
It is also worth pointing out that one of the downsides of having state on both client and the server is the they can get out of sync. It is a solvable problem, sometimes a bit annoying, sometimes absolutely desired, but since you are going over the list of pros and cons, it is worth mentioning it.
Why would a Phoenix application that uses Live View be sending data all the time? Unless you explicitly put the server or the client on a loop, then it is no different than a regular website. Live View is only going to send and receive the data you ask it to (and do it in the best way possible).
Perhaps in the past I’ve been too subtle and not clear enough. My intention was never to critize LiveView - it’s just a technology, a solution approach.
My reaction is to the way a large portion of its supporters are responding to it.
From: Programmers know the benefit of everything and the tradeoffs of nothing:
We are so fixated with ourselves an our own ease of development …
I think we’re very self focused …
… we’re like so infatuated with ourselves …
… but we should be really thinking about the software because that’s what we actually do …
… I want something that’s easy not really far from what I know …
… currently we focus on ourselves, we focus on our own convenience …
… we should be focussing on what we’re making, why are we making it …
… we should instead be focusing on the quality of the software, its correctness, our ability to change it, maintain it …
… and we should be careful when we’re choosing things that we want to do, so we’re not looking at something and saying “I like this because it’s good fro me personally, right now” …
There seems to be a significant contingent of LiveView supporters who are primarily motivated by
rather than
i.e. there seems to be very little focus on what is being built and whether the trade-offs made by any of the employed solution technologies are fit for the intended purpose.
Again you are overly focused on building. The “building” is merely a means to an end. The “real conversation” comes when the end product either fulfills its intended purpose in the context of where it is used or when it fails to meet expectations, possibly due to inappropriate technology choices.
Who cares if the construction crew had an absolute ball “constructing” the house if the completed house is an absolute misery to live in?
I.e. the primary concern should be what is being built and the context that it will be operating in. How it is being built is a secondary concern.
Furthermore the trend is for web clients to take on more of the roles that have been traditionally filled by native apps. So if one is creating a web based Wunderlist clone which is primarily being used from mobile devices when users are travelling on public transit - an environment with notoriously unreliable connection quality - then I don’t see something that has no client based state as a viable option.
The current trend seems to deemphasize “server dependent” (dumb client) applications in favour of “server supported” (smart client) applications. That doesn’t mean that there is no market for “server dependent” applications. But I suspect that “server supported” applications have more growth potential.
Game streaming is pushing the dumb client approach in an effort to lower the barrier of entry to get people hooked on the service with the least amount of resistance. That means offering “gaming” on devices people already own (i.e. don’t have to buy a dedicated piece of hardware like a console). That doesn’t change the fact that many actual “gaming enthusiasts” will prefer the “smart client” approach of running their game-of-choice on the best hardware (e.g. PC) they can afford. Availability of “cheaper than PC” gaming consoles has increased the gaming market, as well as “free-to-play” smart device game apps.
Game streaming may not grow the market at all, simply converting some of the existing console market. If that is the case then streaming is just going to increase the service operational cost without increasing revenue.
It’s a good point. Offline capabilities and rich client-side state requirements should be considered prior to implementing an application with something like LiveView. Where we put logic across client <–> server has costs depending on the application.
The application I’m refactoring is essentially a CRUD HTTP API for a database. There’s some logic on the server (PHP) but it’s mostly an ad-hoc mix of responsibilities coupled to Angular Javascript models. The application generates a PDF with some charts. For some reason there are charts built in Go (another server language!) as well as Javascript (client). Many of the business critical calculations used by the charts are persisted only in a PDF ignoring many reporting requirements entirely. The JSON sent back and forth is littered with Ids and database concerns because that’s all the back-end is: a database on HTTP. Such a mishmash of responsibilities! Requirements to integrate mean rebuilding most of the application.
Moving the domain model of the application from the client to the server, using server rendered HTML, and using Javascript only for things like Charts.js and Puppeteer (PDFs) is going to simplify the application significantly while meeting more business requirements. The app is pretty much lists and forms. The users are in an air conditioned office with a gigabit internet connection. LiveView makes a lot of sense here.
Another side of the business has to do lots of mobile data collection. Photos, forms, work-orders, field service type use cases. Internet connections in the field are unreliable: offline capabilities are required. LiveView is not an good fit especially since some native mobile capabilities are wanted.
In hindsight most of the issues with the PDF application come down to scoping. The developer didn’t have context to integration requirements or even what the business actually needed. Scope of the application shifted frequently as the business didn’t really know either. Everything took two or three times as long and now we need to rebuild most of it. A frustratingly common story in the industry.
The point is you have to know the domain of the app you’re building, and have stakeholder agreement on scope to effectively assert trade-offs of implementation details like LiveView.
Those are not excluding nor conflicting sentences. If someone says, “yay - now I don’t have to deal with the meshugena JavaScript ecosystem (or the browser)”, they may have already evaluated LiveView under their current constraints and reached the conclusion that Live View is a good fit and an alternative to JavaScript, which they reaffirm.
But, even if that’s not the case, people can make the choice of being self-focused and evaluating their own time above the software, I believe we need to accept that’s a valid approach to software development, even if we disagree with it. The Rails community was built on similar principles and it has been successful, although we can also list shortcomings of such approach to development.
We had a recent discussion about NimbleParsec exactly along those lines. I know there is a correct and proper way of writing parsers, but I am honestly not interested in that. When I am working on NimbleParsec, I am valuing my own time and enjoyment above proper parser design. Of course, I wouldn’t do this when working on Elixir itself, client projects, etc.
The argument you would hear from people that favor developer time is that by putting a house first, even if it is miserable, people can start using it early, evaluate it, provide feedback, and then you can make their lives better. Why would I build the most well-engineered house if nobody could afford to live there or if everybody was already living elsewhere?
I am not defending one point of view or the order. I do have my preferences and I believe we should educate people on the trade-offs (ha) but I wouldn’t say people are wrong in picking one or the other.
Very much agree with José - we have limited time and I would prefer to spend that on things I enjoy or find will yield the best value.
For me the backbone of an app is of extreme important - that’s why I would prefer to use Elixir and Phoenix on the backend.
After that, for the kind of app I want to create (a social network), the native apps are also hugely important - so I would prefer to spend my time learning Swift (and the Android equivalent).
Since these kind of apps will predominantly be used on mobile, the web version is less important (to me) because as discussed previously, native apps have considerable benefits - such as access to specialised hardware which can help differentiate apps from the competition to give them an edge
So my time:
But each to their own 
Personally I am very excited to see the kind of apps people will create with LV and I’m fairly sure many of the doubts and concerns will just fade away as the technology proves itself (which I have no doubt it will with Chris and José at the helm!!) 
I believe that this one time you might be the one fixating way too much – on the business side of things. People here are techies & something of businessmen. We can’t judge tech in the way a CEO does it.
We absolutely have to also focus on how do we build things, for many reasons, but mostly because we are supposedly mature professionals who pick the best tools for the job. And by “best” I mean the good technical merit and the smaller cost of ownership – I am not even including other harsh realities like the ability to legate to a junior dev if you get moved to other projects (or switch jobs) or picking tech that your company has most heads knowing about (something I hate but is a factor in a lot of companies).
I appreciate your “no fanboyism allowed” approach but IMO this time you lean way too much to the business side and I might be wrong here but I believe you put too much weight on what’s popular (Javascript). Some people – like myself – have went through 6-10 programming languages and they can have an informed opinion when saying “Elixir is much better fit than PHP, JS or Ruby for this project”. That doesn’t make the programmer a fanboy.
“This company has a lot of programmers knowing PHP” is not a good argument for project planning and never will be. The project will suffer from the normal PHP problems regardless of policy. The company might have more bodies to throw at the problem but that’s not a cost-effective solution at all. It’s mighty expensive. Only choosing the “safe” option has done our area too much damage already.
I believe it’s very normal that people try and find solutions akin to LiveView instead of dealing with Javascript. I disagree with you if you are saying that this is a bad thing.
That was one of the hard requirements of my current job in a college. All pages absolutely have to have a javascript-less fallback that should be functional enough to get all work done (why do you think I like unpoly and drab so much). ^.^
/me is skipping most of the rest of this thread as game streaming and so forth then would do in webassembly anyway for battery and efficiency reasons
Right, which makes it an easy choice given those requirements. My point is a noscript requirement is an increasingly rare requirement. I’m 100% happy to say LiveView won’t target this use-case 
About the nojavascript requirement, is webassembly allowed in this case? Regardless, LiveView can theoretically work over HTTP nojavascript if you hook the actions and make it send GET requests with the json URLencoded into the query. It would be the same like using PHP. (Hook on the serverside and pregenerate the action urls)
About the bandwidth, the bandwidth usage out the box will be MUCH less than a react app. This is because DOM differentials only send the changed parts of a page. For example in a React app you might have a function like, get_customer_list, which you call using AJAX that returns a list of customers, say 20. In LiveVIew this will be the same except the 20 customers that are returned will be diffed on what your client currently has and maybe no data will be sent because the 20 are all the same, or only 1 for example will be sent over.
In react a similar effect can be achieved using state differentials, but as far as I am aware, no serious library at the level of Redux or Saga deals with this.
The only negative of LiveView is the computation cost which the frontend JS used to do, now is moved to the serverside. Technically tho it should be quite negligible, but depending on the complexity of your logic it could require you buying 10x more servers than before. The cost of 10x more 20 core servers a month is around 3000$ a month, now factor in the cost of hiring 3 React developers vs 1 LiveView developer to meet your deadline. And pick.
© Copyright Elixir Forum | Terms | Privacy & Cookies
