9 ms·

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more dif

So, the OP argues that SPAs introduce unnecessary frontend state: "I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult." But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)." I find the ad hoc jQuery+endpoint tangle much harder to reason about than something built with a front end framework and a more uniform API.

bauerd 8y ago
This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).
- basch 8y ago
  is that true? googles auto-suggestions are rendered server side, as you type in the field they update. (unless I am mistake, but I thought that was the case)
  - drewmol 8y ago
    I think it's a combination of local cache immediately, followed up by a server response
  - icebraining 8y ago
    That's not really "rendered" server side; the data is fetched from the server by JavaScript in JSON form, then dynamically inserted into the DOM.
- paulie_a 8y ago
  Honestly no it wouldn't suck and from a end user perspective for a calendar. It is actually far superior. Granted this is only my personal opinion. There seems to be this desire to overcomplicate the front end when simple solutions work quite well. Granted they don't have all the catchy buzzwords. But they make for a better less bug filled solution.
  - bauerd 8y ago
    Calendar UIs commonly demand stuff like auto-refreshing, datetime selects, drag-dropping items around, resizing those, list goes on. Please elaborate how you'd build a "simple solution" that does not resort to client-side rendering.
    - wild_preference 8y ago
      Yeah, even a "Select All" button that checks all checkboxes requires Javascript. Aside: I don't understand the premise of this thread that suggests it's a "SPA" just to, say, use React on a single page of an application. The whole basis of the "SP" in "SPA" is that the Javascript (state) spans multiple pages.
  - PurpleBoxDragon 8y ago
    I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker. It stands out in my memory as one of the worst pieces of software I've ever seen produced.
    - TopWaltz 8y ago
      > I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker ASP.NET Webforms? I have good memories of being able to do that easily, with zero (or almost zero) JavaScript. It's not the best user experience ever (the whole page has to reload after each click, and the state is persisted by serializing structs in <input type="hidden"> fields), but I had a pleasant experience when I developed with it. ASP.NET Webforms components were the best thing until we finally had React/Vue! The only problem was that it was way too easy to make a mess in your backend code.
juandazapata 8y ago
From the blog post > Third, if you’re implementing a very complicated component then you can use React just for that component.
- jhall1468 8y ago
  LOL. So avoid complexity by writing in VanillaJS, but feel free to load an enormous frontend library for a single component. Makes sense.
  - wild_preference 8y ago
    Eh, let's avoid eye-rolling hysterics on this forum and stay practical. There are components that are complex enough to warrant a view library, embedded in an application that's not. In fact, it doesn't take much complexity at all, in my experience. At which point loading a view library a la carte is your only real option. What doesn't make sense about that?
    - jhall1468 8y ago
      There are applications that warrant a view library. There's not a single case where importing two view frameworks with one handling the "complex components" makes any sense. React can also do very simple components. Pick one and run with it. If your application is complex enough to warrant a complex UI library, use a complex UI library. The complexity involved in using two different libraries that handle the rendering in very different ways (one doesn't even do the rendering, so now you have two rendering solutions in addition to two view libraries. Yay!) in the name of simplifying your code is an absolute joke.
  - PurpleBoxDragon 8y ago
    I'd assume it is to have a enormous front end library to handle all your complicated components and the author would be horrified by the prospect of every component written with a different front end library. It does present an issue if you literally have a single component that needs it, but I think this advice was aimed at cases where there are many such complicated components.
toolz 8y ago
There are some interesting implementations out there taking advantage of persistent connections to allow the server to handle the rendering while having targeted fragment updates come from the server. Here's a thread I posted about some FOSS I've been working on that relies entirely on the server for rendering and using VDOM diff/patching on the server for updates. I'm definitely biased, but in my opinion this approach is vastly more user friendly because it enables realtime data updates as easily as request/response style updates. here's the thread https://news.ycombinator.com/item?id=18318415 https://news.ycombinator.com/item?id=18318415 if you need some click bait, here's a gif of me in seattle over cell phone internet interacting with a SSR realtime app with the server in cali. https://imgur.com/z8pKt8t https://imgur.com/z8pKt8t - all operations going round trip, with no application level JS written
- sj3k 8y ago
  Is this kinda how next.js works? I have not used it myself but I think it looks neat.
  - toolz 8y ago
    I believe nextjs is just taking react and rendering the initial page load on the server. So this library (texas) and nextjs don't really have much in common.
    - sj3k 8y ago
      Thanks! Texas looks awesome.
- thecatspaw 8y ago
  having worked with JSF, I can safely say that me and server side rendering with peristent client connection to push updates are ... not friends. You have multiple scopes in the same document. You have the jsp scopes which gets rendered once, when the client requests the page, and the jsf scope which lives longer. Initially when rendering these scopes seem to share variables, but after the request is rendered, the jsp scope gets removed
deleted 8y ago
[deleted]
swiley 8y ago
HTML has support for everything you listed without resorting to JavaScript. Maybe some sort of graphic editor for a special file type isn’t possible without JavaScript? But most things really have been thought of and incorporated into html.
- vetinari 8y ago
  HTML doesn't have support for autocomplete elements and conditional input elements. Even date pickers are spotty.
  - ben_jones 8y ago
    Datepickers, specifically datetime pickers, in pure html are vomit inducing.
ishi 8y ago
I agree, but using a front-end framework does not mean you must build your entire app as an SPA. You can still have separate pages, and UI components on each page get handled by your framework of choice. Also, there's a big difference between the state of a single form vs. keeping the state of your whole application in the frontend!
- dzwillia 8y ago
  ...and this is really what it comes down to. State management should come down to what the front end has to manage in order to be well-organized and structured. By creating a multi-page app, all you are doing is forcing yourself to organize your state by page. This is something that can be done simply enough by using modules in your state manager of choice. With a SPA, you have the option, with MPA, the decision of overall organization has already been made.
nicklasss 8y ago
That's why I love to use Vue to handle complex frontend states without building a full SPA
thecatspaw 8y ago
With SPA you usually dont add frontend state on top of backend state, you only have the frontend part, and a stateless API. This makes it very easy to test and reason about.
- marcosdumay 8y ago
  > stateless API Does it not access any data?
  - TimJYoung 8y ago
    Most JSON/data APIs for SPAs are similar to SQL database servers: maintaining a persistent connection is useful for performance reasons, but there's nothing about the API that dictates that it's required. The only state that is required across API calls is an authenticated session, and that is maintained on the server side.
    - thecatspaw 8y ago
      and even authentication can be done stateless. Makes load balancing easy since each request can go to a different server
  - throwaway2016a 8y ago
    It is generally accepted that when someone uses the phase "stateless API" they mean session state not data persistence.
    - marcosdumay 8y ago
      Yes, and this does nothing to help with the problem of state coherence between the backend and frontend.
rpeden 8y ago
I'm not sure stateful vs stateless is even the right way to frame it. With no JavaScript at all, your application is still stateful. Even if an individual HTTP request is stateless, your app as a whole still has state. The state just lives in the database in that case, and each request you make either gives you a view of part or all of its current state or provides data to transition the application from one valid state to another valid state. Actually, thinking of an application as a series of transitions between valid states is why I enjoy using things like Redux. Used properly, it acts as a gatekeeper that makes it hard to move the application from a valid state to an invalid one. It adds a fair amount of boilerplate, though, which I know some people find frustrating. Maintaining state on the front end and keeping it in sync with the back end is a pain. But I don't think it has to be. it's just an artifact of us being stuck in a certain paradigm of application development that we don't seem to be able to get out of. It wouldn't be impossible to design a system that runs over a network, but doesn't require the front-line application developer to think about the network. It sounds like something Alan Kay might have worked on at some point. :) I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. And when it receives this message, it transmits itself across the network, validates its data, and persists itself into a database. Maybe an object database like Gemstone/S. But the application developer wouldn't have to worry about all the details most of the time. Just tell the object to save itself, and it'll report back whether it was able to or not, so you can update the application accordingly. I'm sure I'm overlooking a ton of potential pitfalls, of course. I think we can do a lot better than we're doing right now, but I'm not 100% certain what better looks like, or quite how to get there. Maybe I just need to watch a few Bret Victor talks for inspiration and then get to work trying to build something. :)
- jrochkind1 8y ago
  > I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. It sounds to me like "what if Javascript had SOAP", heh. We can envision lots of things. The beauty of software engineering/architecture is you can envision almost anything. The trick is that the more complex the thing is, the harder it is to pull of _well_, and the easier it is to end up with a monster. The complicated things take more expertise/skill/experience to design, and _also_ take more development time to produce -- and on an ongoing basis to maintain. And it's not always clear where development resources come from on 'shared commons' like platforms (unless they are proprietary and only available for a fee). The current front-end JS environment is already _pretty darn complex_ of course. How well it's pulling it off, well, is a matter of debate central to the OP. On, and then there's getting different actors to coordinate in thing that require that (like browser's supporting something). I can envision it too. But I wouldn't wager much on it happening in a way that actually results in an improved development environment (instead of a monster).
jolmg 8y ago
That's like saying that if you have to kill a fly, why opt for swatter when you can use a bazooka? After spending some years building an SPA webapp, I'm really missing the simplicity of stateless HTML. The front-end framework my colleagues picked really likes to carry state around, like between pages, which has caused numerous hard-to-find bugs. These bugs are triggered when you do certain sequence of actions across multiple pages. That stuff should be impossible. We really ought clear all state between pages, but apparently it's harder to fight the framework to do this. Carrying state around is just fundamental for it. I'm currently on hiatus from that project to work on a small one that's needed quick. So far, I haven't used a single line of javascript, and it's a multi-page form. I can add, remove, and edit rows from an HTML table without javascript or server side state. Instead of an autocomplete input, I used an input and search button and had the server return a page with search results to select from. State is maintained through inputs, hidden or not. Different submit buttons perform different actions, but they all send all fields to be re-rendered in the next page. I gotta say, it's just refreshing to do things this way after so much time. It's super-responsive not having to load and run bunches of javascript. It's also cool to see the forward and back buttons work for free, without any special consideration on my part. I can use them to replay every action I've taken in the form, all additions, edits, and removals of rows in the aforementioned HTML table, and the different form pages. Were I asked to do things "prettier" (to somebody else's standard of what's pretty), I would just use minimal javascript. There is no reason to go all-in with a front-end framework just for a dynamic datepicker.
- TimJYoung 8y ago
  Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathize. Nobody wants to transfer state across page loads, it's a mess...
  - jolmg 8y ago
    The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.
reaperducer 8y ago
But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)." In my experience, this is false. In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts, but had to be multi-lingual, predictive, mobile-friendly, and fully accessible. They use all those little bits that you talk about - multi-part forms, date pickers, autocomplete, and conditional input. The only JS is for the autocomplete. The rest is all HTML5/CSS3. We did user testing on three of them (100 people from our target group, selected randomly at two of our facilities, with generally low levels of technology literacy), and the paginated HTML5/CSS3 versions all scored higher than the previous Javascript SPA mess the preceded them.
- rovek 8y ago
  If you didn't use JS for date pickers, you didn't have very inclusive browser support - especially for something like a healthcare website. [1] Were the designs and layout of these SPA and HTML5/CSS3 website also identical? [1] https://caniuse.com/#search=input%20date https://caniuse.com/#search=input%20date
  - bunderbunder 8y ago
    If it's public facing, that's a huge concern. If it's intended for business users, particularly if on an intranet site, it's often very easy to limit the number of browsers and versions you need to support to just a handful.
    - Isofarro 8y ago
      The Web has been collecting dates from users in forms long before date-pickers existed.
      - 8y ago
dagoat 8y ago
You don't have to use jQuery... https://news.ycombinator.com/item?id=18336429 https://news.ycombinator.com/item?id=18336429
PurpleBoxDragon 8y ago
You do still have state, but with a MPA you have a cleaner break between each page and thus far less ability for state to persist and cause problems (though there are plenty of technologies to shoot yourself in the foot if you so desire). I wonder if the most optimal solution is to have a MPA but using some SPA technology. This reduces the overall state of every page, but still gives you decent technology to work with the state of the page that you just cannot do away with.
wstuartcl 8y ago
shrug That feels like a straw man, you can obviously also use modern js and a decent framework (vue react whatever) to make the portions of the page that need state, transitions and complex interactions very user friendly and easy to reason about without pulling the entire site or section of site up into an SPA. I have seen far too many implementations pull whole sites or large sections of sites up to SPA to mitigate one complex form or stateful interaction area. There is obviously a range of implementations that can be done from SPA|--------------------------|Page-Level and none of the areas on that spectrum require you to do anything in a"jquery tangle" let alone with any jquery include at all.
- flanbiscuit 8y ago
  The author recommends that as an option as well > Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React. The same applies to Vue.js and the rest of the pack.
TimJYoung 8y ago
My problem with the idea that SPAs, as an idea, are inherently more difficult to develop is that this doesn't translate to desktop/mobile applications, which are, conceptually, very similar in architecture (fat UI client, app server on the back-end). What may be more true is that the way in which we develop SPAs is so flawed that it causes serious issues with quality/development effort. IOW, perhaps the issue is with JS and its limitations with large, complex client applications, not the SPA architecture. Disclaimer: my company sells a web development product that creates SPAs that work like desktop applications.
illiac_1962 8y ago
Queue up a huge debate that essentially results in qualifying web development as the train wreck dumpster fire school shooting that it is. Painful in many ways all at once.
koolba 8y ago
Or just have multiple pages with the complicated ones rendered with something like React. Nothing stops you from having more than one app bundle and with proper packaging it’s not even particularly slower to download or parse.
vivekseth 8y ago
You are making a false comparison. Why would an SPA not be a "ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries" ? I think it's quite possible to design an SPA like that.

bauerd 8y ago

This is true, the author seems to imply that it's somehow possible to always avoid complex UI state. Might be true for some UIs, but definitely not for all (e.g. a calendar UI would suck big time when rendered exclusively on the server-side).

basch 8y ago
is that true? googles auto-suggestions are rendered server side, as you type in the field they update. (unless I am mistake, but I thought that was the case)
- drewmol 8y ago
  I think it's a combination of local cache immediately, followed up by a server response
- icebraining 8y ago
  That's not really "rendered" server side; the data is fetched from the server by JavaScript in JSON form, then dynamically inserted into the DOM.
paulie_a 8y ago
Honestly no it wouldn't suck and from a end user perspective for a calendar. It is actually far superior. Granted this is only my personal opinion. There seems to be this desire to overcomplicate the front end when simple solutions work quite well. Granted they don't have all the catchy buzzwords. But they make for a better less bug filled solution.
- bauerd 8y ago
  Calendar UIs commonly demand stuff like auto-refreshing, datetime selects, drag-dropping items around, resizing those, list goes on. Please elaborate how you'd build a "simple solution" that does not resort to client-side rendering.
  - wild_preference 8y ago
    Yeah, even a "Select All" button that checks all checkboxes requires Javascript. Aside: I don't understand the premise of this thread that suggests it's a "SPA" just to, say, use React on a single page of an application. The whole basis of the "SP" in "SPA" is that the Javascript (state) spans multiple pages.
- PurpleBoxDragon 8y ago
  I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker. It stands out in my memory as one of the worst pieces of software I've ever seen produced.
  - TopWaltz 8y ago
    > I once worked with a guy who built an app with everything done server side in web forms, including a datetime picker ASP.NET Webforms? I have good memories of being able to do that easily, with zero (or almost zero) JavaScript. It's not the best user experience ever (the whole page has to reload after each click, and the state is persisted by serializing structs in <input type="hidden"> fields), but I had a pleasant experience when I developed with it. ASP.NET Webforms components were the best thing until we finally had React/Vue! The only problem was that it was way too easy to make a mess in your backend code.

juandazapata 8y ago

From the blog post > Third, if you’re implementing a very complicated component then you can use React just for that component.

jhall1468 8y ago
LOL. So avoid complexity by writing in VanillaJS, but feel free to load an enormous frontend library for a single component. Makes sense.
- wild_preference 8y ago
  Eh, let's avoid eye-rolling hysterics on this forum and stay practical. There are components that are complex enough to warrant a view library, embedded in an application that's not. In fact, it doesn't take much complexity at all, in my experience. At which point loading a view library a la carte is your only real option. What doesn't make sense about that?
  - jhall1468 8y ago
    There are applications that warrant a view library. There's not a single case where importing two view frameworks with one handling the "complex components" makes any sense. React can also do very simple components. Pick one and run with it. If your application is complex enough to warrant a complex UI library, use a complex UI library. The complexity involved in using two different libraries that handle the rendering in very different ways (one doesn't even do the rendering, so now you have two rendering solutions in addition to two view libraries. Yay!) in the name of simplifying your code is an absolute joke.
- PurpleBoxDragon 8y ago
  I'd assume it is to have a enormous front end library to handle all your complicated components and the author would be horrified by the prospect of every component written with a different front end library. It does present an issue if you literally have a single component that needs it, but I think this advice was aimed at cases where there are many such complicated components.

toolz 8y ago

There are some interesting implementations out there taking advantage of persistent connections to allow the server to handle the rendering while having targeted fragment updates come from the server. Here's a thread I posted about some FOSS I've been working on that relies entirely on the server for rendering and using VDOM diff/patching on the server for updates. I'm definitely biased, but in my opinion this approach is vastly more user friendly because it enables realtime data updates as easily as request/response style updates. here's the thread https://news.ycombinator.com/item?id=18318415 https://news.ycombinator.com/item?id=18318415 if you need some click bait, here's a gif of me in seattle over cell phone internet interacting with a SSR realtime app with the server in cali. https://imgur.com/z8pKt8t https://imgur.com/z8pKt8t - all operations going round trip, with no application level JS written

sj3k 8y ago
Is this kinda how next.js works? I have not used it myself but I think it looks neat.
- toolz 8y ago
  I believe nextjs is just taking react and rendering the initial page load on the server. So this library (texas) and nextjs don't really have much in common.
  - sj3k 8y ago
    Thanks! Texas looks awesome.
thecatspaw 8y ago
having worked with JSF, I can safely say that me and server side rendering with peristent client connection to push updates are ... not friends. You have multiple scopes in the same document. You have the jsp scopes which gets rendered once, when the client requests the page, and the jsf scope which lives longer. Initially when rendering these scopes seem to share variables, but after the request is rendered, the jsp scope gets removed

deleted 8y ago

[deleted]

swiley 8y ago

HTML has support for everything you listed without resorting to JavaScript. Maybe some sort of graphic editor for a special file type isn’t possible without JavaScript? But most things really have been thought of and incorporated into html.

vetinari 8y ago
HTML doesn't have support for autocomplete elements and conditional input elements. Even date pickers are spotty.
- ben_jones 8y ago
  Datepickers, specifically datetime pickers, in pure html are vomit inducing.

ishi 8y ago

I agree, but using a front-end framework does not mean you must build your entire app as an SPA. You can still have separate pages, and UI components on each page get handled by your framework of choice. Also, there's a big difference between the state of a single form vs. keeping the state of your whole application in the frontend!

dzwillia 8y ago
...and this is really what it comes down to. State management should come down to what the front end has to manage in order to be well-organized and structured. By creating a multi-page app, all you are doing is forcing yourself to organize your state by page. This is something that can be done simply enough by using modules in your state manager of choice. With a SPA, you have the option, with MPA, the decision of overall organization has already been made.

nicklasss 8y ago

That's why I love to use Vue to handle complex frontend states without building a full SPA

thecatspaw 8y ago

With SPA you usually dont add frontend state on top of backend state, you only have the frontend part, and a stateless API. This makes it very easy to test and reason about.

marcosdumay 8y ago
> stateless API Does it not access any data?
- TimJYoung 8y ago
  Most JSON/data APIs for SPAs are similar to SQL database servers: maintaining a persistent connection is useful for performance reasons, but there's nothing about the API that dictates that it's required. The only state that is required across API calls is an authenticated session, and that is maintained on the server side.
  - thecatspaw 8y ago
    and even authentication can be done stateless. Makes load balancing easy since each request can go to a different server
- throwaway2016a 8y ago
  It is generally accepted that when someone uses the phase "stateless API" they mean session state not data persistence.
  - marcosdumay 8y ago
    Yes, and this does nothing to help with the problem of state coherence between the backend and frontend.

rpeden 8y ago

I'm not sure stateful vs stateless is even the right way to frame it. With no JavaScript at all, your application is still stateful. Even if an individual HTTP request is stateless, your app as a whole still has state. The state just lives in the database in that case, and each request you make either gives you a view of part or all of its current state or provides data to transition the application from one valid state to another valid state. Actually, thinking of an application as a series of transitions between valid states is why I enjoy using things like Redux. Used properly, it acts as a gatekeeper that makes it hard to move the application from a valid state to an invalid one. It adds a fair amount of boilerplate, though, which I know some people find frustrating. Maintaining state on the front end and keeping it in sync with the back end is a pain. But I don't think it has to be. it's just an artifact of us being stuck in a certain paradigm of application development that we don't seem to be able to get out of. It wouldn't be impossible to design a system that runs over a network, but doesn't require the front-line application developer to think about the network. It sounds like something Alan Kay might have worked on at some point. :) I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. And when it receives this message, it transmits itself across the network, validates its data, and persists itself into a database. Maybe an object database like Gemstone/S. But the application developer wouldn't have to worry about all the details most of the time. Just tell the object to save itself, and it'll report back whether it was able to or not, so you can update the application accordingly. I'm sure I'm overlooking a ton of potential pitfalls, of course. I think we can do a lot better than we're doing right now, but I'm not 100% certain what better looks like, or quite how to get there. Maybe I just need to watch a few Bret Victor talks for inspiration and then get to work trying to build something. :)

jrochkind1 8y ago
> I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. It sounds to me like "what if Javascript had SOAP", heh. We can envision lots of things. The beauty of software engineering/architecture is you can envision almost anything. The trick is that the more complex the thing is, the harder it is to pull of _well_, and the easier it is to end up with a monster. The complicated things take more expertise/skill/experience to design, and _also_ take more development time to produce -- and on an ongoing basis to maintain. And it's not always clear where development resources come from on 'shared commons' like platforms (unless they are proprietary and only available for a fee). The current front-end JS environment is already _pretty darn complex_ of course. How well it's pulling it off, well, is a matter of debate central to the OP. On, and then there's getting different actors to coordinate in thing that require that (like browser's supporting something). I can envision it too. But I wouldn't wager much on it happening in a way that actually results in an improved development environment (instead of a monster).

jolmg 8y ago

That's like saying that if you have to kill a fly, why opt for swatter when you can use a bazooka? After spending some years building an SPA webapp, I'm really missing the simplicity of stateless HTML. The front-end framework my colleagues picked really likes to carry state around, like between pages, which has caused numerous hard-to-find bugs. These bugs are triggered when you do certain sequence of actions across multiple pages. That stuff should be impossible. We really ought clear all state between pages, but apparently it's harder to fight the framework to do this. Carrying state around is just fundamental for it. I'm currently on hiatus from that project to work on a small one that's needed quick. So far, I haven't used a single line of javascript, and it's a multi-page form. I can add, remove, and edit rows from an HTML table without javascript or server side state. Instead of an autocomplete input, I used an input and search button and had the server return a page with search results to select from. State is maintained through inputs, hidden or not. Different submit buttons perform different actions, but they all send all fields to be re-rendered in the next page. I gotta say, it's just refreshing to do things this way after so much time. It's super-responsive not having to load and run bunches of javascript. It's also cool to see the forward and back buttons work for free, without any special consideration on my part. I can use them to replay every action I've taken in the form, all additions, edits, and removals of rows in the aforementioned HTML table, and the different form pages. Were I asked to do things "prettier" (to somebody else's standard of what's pretty), I would just use minimal javascript. There is no reason to go all-in with a front-end framework just for a dynamic datepicker.

TimJYoung 8y ago
Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathize. Nobody wants to transfer state across page loads, it's a mess...
- jolmg 8y ago
  The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.

reaperducer 8y ago

But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)." In my experience, this is false. In the last two years I've built five very complex forms for the healthcare industry that not only had crazy looking flow-charts, but had to be multi-lingual, predictive, mobile-friendly, and fully accessible. They use all those little bits that you talk about - multi-part forms, date pickers, autocomplete, and conditional input. The only JS is for the autocomplete. The rest is all HTML5/CSS3. We did user testing on three of them (100 people from our target group, selected randomly at two of our facilities, with generally low levels of technology literacy), and the paginated HTML5/CSS3 versions all scored higher than the previous Javascript SPA mess the preceded them.

rovek 8y ago
If you didn't use JS for date pickers, you didn't have very inclusive browser support - especially for something like a healthcare website. [1] Were the designs and layout of these SPA and HTML5/CSS3 website also identical? [1] https://caniuse.com/#search=input%20date https://caniuse.com/#search=input%20date
- bunderbunder 8y ago
  If it's public facing, that's a huge concern. If it's intended for business users, particularly if on an intranet site, it's often very easy to limit the number of browsers and versions you need to support to just a handful.
  - Isofarro 8y ago
    The Web has been collecting dates from users in forms long before date-pickers existed.
    - 8y ago

dagoat 8y ago

You don't have to use jQuery... https://news.ycombinator.com/item?id=18336429 https://news.ycombinator.com/item?id=18336429

PurpleBoxDragon 8y ago

You do still have state, but with a MPA you have a cleaner break between each page and thus far less ability for state to persist and cause problems (though there are plenty of technologies to shoot yourself in the foot if you so desire). I wonder if the most optimal solution is to have a MPA but using some SPA technology. This reduces the overall state of every page, but still gives you decent technology to work with the state of the page that you just cannot do away with.

wstuartcl 8y ago

shrug That feels like a straw man, you can obviously also use modern js and a decent framework (vue react whatever) to make the portions of the page that need state, transitions and complex interactions very user friendly and easy to reason about without pulling the entire site or section of site up into an SPA. I have seen far too many implementations pull whole sites or large sections of sites up to SPA to mitigate one complex form or stateful interaction area. There is obviously a range of implementations that can be done from SPA|--------------------------|Page-Level and none of the areas on that spectrum require you to do anything in a"jquery tangle" let alone with any jquery include at all.

flanbiscuit 8y ago
The author recommends that as an option as well > Third, if you’re implementing a very complicated component then you can use React just for that component. For instance, if you’re building a chat box then there’s really no need to implement your login page in React. The same applies to Vue.js and the rest of the pack.

TimJYoung 8y ago

My problem with the idea that SPAs, as an idea, are inherently more difficult to develop is that this doesn't translate to desktop/mobile applications, which are, conceptually, very similar in architecture (fat UI client, app server on the back-end). What may be more true is that the way in which we develop SPAs is so flawed that it causes serious issues with quality/development effort. IOW, perhaps the issue is with JS and its limitations with large, complex client applications, not the SPA architecture. Disclaimer: my company sells a web development product that creates SPAs that work like desktop applications.

illiac_1962 8y ago

Queue up a huge debate that essentially results in qualifying web development as the train wreck dumpster fire school shooting that it is. Painful in many ways all at once.

koolba 8y ago

Or just have multiple pages with the complicated ones rendered with something like React. Nothing stops you from having more than one app bundle and with proper packaging it’s not even particularly slower to download or parse.

vivekseth 8y ago

You are making a false comparison. Why would an SPA not be a "ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries" ? I think it's quite possible to design an SPA like that.