4 ms·

"Single page" isn't the why it's the how. It enables you to take a JavaScript-first approach which in turn makes building complicated applications easier.

by ng12 7y ago

henrikschroder 7y ago
> It enables you to take a JavaScript-first approach Uh-huh... > which in turn makes building complicated applications easier. What? This is vacuous market-speak.
- ng12 7y ago
  I mean... not really. I wouldn't invest in building client-side applications unless they bought me something. My customers don't really care, the majority don't even know what an SPA is. They do care that our application is faster and has more features than our competitors.
- wyqydsyq 7y ago
  To word it more technically, building an SPA allows you to build applications as declarative composable functions which are deterministic, as opposed to the spaghetti code commonly seen in the days of jQuery and PHP which is harder to read, reason about, debug and maintain due to their imperative and nondeterministic nature.
  - henrikschroder 7y ago
    I literally can't tell if your comment is satire or not. I hope it is. I fear it isn't.
    - wyqydsyq 7y ago
      It isn't. I elaborated a bit in my later comment: https://news.ycombinator.com/item?id=22523344 https://news.ycombinator.com/item?id=22523344
  - rovr138 7y ago
    > building an SPA allows you to build applications as declarative composable functions which are deterministic How is that not the definition of a function or a method? Deterministic in what sense? It’s output? It’s input? Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.
    - wyqydsyq 7y ago
      > How is that not the definition of a function or a method? It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out. > Deterministic in what sense? It’s output? It’s input? What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output. PWAs are generally deterministic because they're just functions that take an input and give you back a DOM. Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input, it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one. > Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language. This has nothing to do with languages, it's about project architecture and programming paradigms. The classic webserver+jQuery type architecture is inherently imperative. Of course it can have little islands of functionally pure, declarative code, but the overall software architecture is still imperative. In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.
  - mrmonkeyman 7y ago
    This must be satire. Literally every sentence is wrong.
  - deleted 7y ago
    [deleted]
  - vanviegen 7y ago
    Well, I'd argue that old fashioned PHP sites are structurally really similar to modern declarative client-side UIs, in that in both cases your're basically just constructing a series of functions that (deterministically) convert the current state to HTML. Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast. And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required. If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
    - wyqydsyq 7y ago
      Yeah fair call and it's more the combination of PHP + jQuery I'm referring to as being non-deterministic rather than either on their own - you can definitely write deterministic PHP and jQuery code, but the implicit integration between them (PHP rendering HTML which becomes a DOM which jQuery imperatively operates on) is what I'm saying makes it non-deterministic. I'm mostly talking about the part you mentioned in managing client-side state using a non-declarative paradigm, where you either end up with a stupid amount of unnecessary complexity (conditions checking the prior state of literally any and everything you touch, I've never really seen this in a production project) or making naive assumptions about the DOM which means non-deterministic and potentially unexpected behaviour. > If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously! Fair point but there's also a flip-side to this though. You can write a client-side PWA with all your async state and data persistence magically handled by a service like Firebase Cloud Firestore, so just writing the UI declaratively and not having to worry at all about servers or databases, which generally requires a lot more upfront planning (figuring out models/schemas to represent your data, service architecture etc) than just slapping a UI together and wiring inputs up to a production-ready persistence layer API in front of a schemaless NoSQL DB like Firebase.
- com2kid 7y ago
  SPA gives you all the state stored client side, backend can be reduced to simple stateless functions. Anything persisted longer goes in the DB, and plenty of solutions exist that automatically keep the client side view of the DB and the backend in sync automatically, even across temporary loss of connectivity. Compared to the bad days of server side session management, SPAs are far simpler to code and to reason about. The elimination of the back and forth between client and backend means far less testing, and far simpler testing. It is also arguably more efficient. Yes it uses more resources on the client compared to doing everything server side, but cpu and memory needs to be used no matter what. Treating web browsers as dumb terminals when the cheapest smartphone is at least quad core is a bit silly. That said, there isn't any excuse for bad client side code that murders CPUs, but not using the client for anything but JPEG decoding doesn't make much sense!

"Single page" isn't the why it's the how. It enables you to take a JavaScript-first approach which in turn makes building complicated applications easier.

by ng12 7y ago

"Single page" isn't the why it's the how. It enables you to take a JavaScript-first approach which in turn makes building complicated applications easier.

henrikschroder 7y ago

> It enables you to take a JavaScript-first approach Uh-huh... > which in turn makes building complicated applications easier. What? This is vacuous market-speak.

ng12 7y ago
I mean... not really. I wouldn't invest in building client-side applications unless they bought me something. My customers don't really care, the majority don't even know what an SPA is. They do care that our application is faster and has more features than our competitors.
wyqydsyq 7y ago
To word it more technically, building an SPA allows you to build applications as declarative composable functions which are deterministic, as opposed to the spaghetti code commonly seen in the days of jQuery and PHP which is harder to read, reason about, debug and maintain due to their imperative and nondeterministic nature.
- henrikschroder 7y ago
  I literally can't tell if your comment is satire or not. I hope it is. I fear it isn't.
  - wyqydsyq 7y ago
    It isn't. I elaborated a bit in my later comment: https://news.ycombinator.com/item?id=22523344 https://news.ycombinator.com/item?id=22523344
- rovr138 7y ago
  > building an SPA allows you to build applications as declarative composable functions which are deterministic How is that not the definition of a function or a method? Deterministic in what sense? It’s output? It’s input? Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.
  - wyqydsyq 7y ago
    > How is that not the definition of a function or a method? It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out. > Deterministic in what sense? It’s output? It’s input? What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output. PWAs are generally deterministic because they're just functions that take an input and give you back a DOM. Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input, it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one. > Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language. This has nothing to do with languages, it's about project architecture and programming paradigms. The classic webserver+jQuery type architecture is inherently imperative. Of course it can have little islands of functionally pure, declarative code, but the overall software architecture is still imperative. In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.
- mrmonkeyman 7y ago
  This must be satire. Literally every sentence is wrong.
- deleted 7y ago
  [deleted]
- vanviegen 7y ago
  Well, I'd argue that old fashioned PHP sites are structurally really similar to modern declarative client-side UIs, in that in both cases your're basically just constructing a series of functions that (deterministically) convert the current state to HTML. Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast. And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required. If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
  - wyqydsyq 7y ago
    Yeah fair call and it's more the combination of PHP + jQuery I'm referring to as being non-deterministic rather than either on their own - you can definitely write deterministic PHP and jQuery code, but the implicit integration between them (PHP rendering HTML which becomes a DOM which jQuery imperatively operates on) is what I'm saying makes it non-deterministic. I'm mostly talking about the part you mentioned in managing client-side state using a non-declarative paradigm, where you either end up with a stupid amount of unnecessary complexity (conditions checking the prior state of literally any and everything you touch, I've never really seen this in a production project) or making naive assumptions about the DOM which means non-deterministic and potentially unexpected behaviour. > If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously! Fair point but there's also a flip-side to this though. You can write a client-side PWA with all your async state and data persistence magically handled by a service like Firebase Cloud Firestore, so just writing the UI declaratively and not having to worry at all about servers or databases, which generally requires a lot more upfront planning (figuring out models/schemas to represent your data, service architecture etc) than just slapping a UI together and wiring inputs up to a production-ready persistence layer API in front of a schemaless NoSQL DB like Firebase.
com2kid 7y ago
SPA gives you all the state stored client side, backend can be reduced to simple stateless functions. Anything persisted longer goes in the DB, and plenty of solutions exist that automatically keep the client side view of the DB and the backend in sync automatically, even across temporary loss of connectivity. Compared to the bad days of server side session management, SPAs are far simpler to code and to reason about. The elimination of the back and forth between client and backend means far less testing, and far simpler testing. It is also arguably more efficient. Yes it uses more resources on the client compared to doing everything server side, but cpu and memory needs to be used no matter what. Treating web browsers as dumb terminals when the cheapest smartphone is at least quad core is a bit silly. That said, there isn't any excuse for bad client side code that murders CPUs, but not using the client for anything but JPEG decoding doesn't make much sense!