I have no doubt there are requirements out there for JS disabled clients, and if you have such requirements then LiveView isn’t a good fit. That said, in my ~10 years of consulting across dozens of projects and domains, I have never, not once, had a requirement to handle clients without JavaScript.
If you have those requirements, LiveView is not for you, but I don’t think we should hang LV’s merits on this aspect.
Please define excellent battery life 
For me “excellent” would last several days. But anyway iPhones and Android battery lives are partially defined by how much they can put their antennae to sleep. I assure you that your iPhone with an app that prevents its antenna from going to sleep is going to deplete its battery in a few hours at most.
Of they will, I agree. They (the better ones) have more than enough power to be used as PC already, and only lack proper OSes that would offer adaptable UIs.
But because they have so much power already, they can run the game engines just fine, and this would require proper tests but I’d wager that it would drain the battery more to use the network so much in order to show a video (30 fps? 60 fps? No people have started to ask for 120…) than to compute the frames locally.
When I studied gaming tech in university 10 years ago, there were people thinking that soon it would be possible to play on a potato with powerful servers rendering the frames from afar. Such companies exist now but because users want better and better resolutions, with higher and higher fps, it won’t do. Or more precisely, I think it will become viable when optic fibers will be everywhere.
So, rendering a game on a server to display it via a potato (phone, small PC, …): yes but only when docked with access to optic fibre network. 5g will be way too power hungry for that.
Hahaha for that you best get a Kindle 
I would expect similar battery life to streaming youtube videos 
I’m sure other people with different requirements won’t see a problem with that indeed! It’s a personal choice, as someone who activates JS only when necessary and don’t like when basic HTML behaviours begin to require JS.
What a world we live in that considers a few days of battery life to be too much
Youtube videos are optimised for streaming, and that is done ahead of time with algorithms which take advantage of the whole video and plenty of CPU/GPU power as time is not a problem. So it cannot be as optimised, really. I would be curious to find out how less optimised it would be network-wise though…
Personal choice is a fair argument to use or not use LiveView, but claiming you “don’t see the point of LV outside of corp LANs” because how you personally choose to browse the web is a bit of hyperbole.
This is technically possible in my country’s 4G network today. The real issue are the carriers with the limits and price tags they put in place. So while many awesome things are possible even today, they don’t happen until somebody is satisfied that these awesome things will be a cash cow.
Ah, but I do think that outside of LANs it might become a problem (depending on how it is done of course) as people will prefer using competing websites that won’t drain their batteries so much by sending data through the net all the time. It is not easy to see where the happy medium lays, and I might be too pessimistic here, but there is an equilibrium to be reached between developers ease of use (and doing everything in one language on the server sure helps) and users happiness, and considering the mean power of even phones today I think more should be done on the client side to save battery life and quicken the interaction.
As an aside, I know Liveview is not the same beast as drab, but my curiosity led me to the drab website the other day. There was a very small preview on the page which didn’t do much, I went to bed and got awoken during the night by my PC fans. When I went to check several years later I could see my single webpage open on the drap site had been using 100% cpu, during the whole night. That’s not a good use of resources, and I hope you will make Liveview the leanest possible for both network and cpu!
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
