10 ms·

As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern.

As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern. For these kinds of web application a server-heavy architecture was always a good choice.

lucasyvas 5y ago
Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported. You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money." You can always add, yes. But why do I have to? The world has treated web and native as separate for far too long. We're really just squabbling over UI toolkits, so why can't we come up with something that just says "Fuck it, we're supporting both native and web as first class in every server framework because that's how it should be. And we're also going to let you use any language in the browser because that's how it should be"
- funcDropShadow 5y ago
  Yes, but as engineers we should strive for the simplest possible approach that solves the problem in a maintainable way. Always choosing the most flexible / the most scalable / the most modern approach is often a waste of resources. > why do I have to add a new paradigm? The answer to that question also depends on which paradigm you are using currently, not only on which you are choosing for the future.
- girvo 5y ago
  I hope one day we can. Though the incredibly tightly coupled server-side-logic nature of LiveView is, I think, a bad fit for the intermittent network architecture of mobile devices. But in theory I see no reason why you couldn’t deliver LiveView to some mobile runtime that controls its native UI via some abstraction layer. Hell, some of the React Native stuff I’ve seen gets close already.

lucasyvas 5y ago

Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported. You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money." You can always add, yes. But why do I have to? The world has treated web and native as separate for far too long. We're really just squabbling over UI toolkits, so why can't we come up with something that just says "Fuck it, we're supporting both native and web as first class in every server framework because that's how it should be. And we're also going to let you use any language in the browser because that's how it should be"

funcDropShadow 5y ago
Yes, but as engineers we should strive for the simplest possible approach that solves the problem in a maintainable way. Always choosing the most flexible / the most scalable / the most modern approach is often a waste of resources. > why do I have to add a new paradigm? The answer to that question also depends on which paradigm you are using currently, not only on which you are choosing for the future.
girvo 5y ago
I hope one day we can. Though the incredibly tightly coupled server-side-logic nature of LiveView is, I think, a bad fit for the intermittent network architecture of mobile devices. But in theory I see no reason why you couldn’t deliver LiveView to some mobile runtime that controls its native UI via some abstraction layer. Hell, some of the React Native stuff I’ve seen gets close already.