5 ms·

Please could you inform me how you would build a form that creates, lets say a secondary loan for a company with attached assets. The assets could be zero, or m

Please could you inform me how you would build a form that creates, lets say a secondary loan for a company with attached assets. The assets could be zero, or many. How would you create this form without Javascript? Would you require a user to create the assets before the loan? Saying that HTML provides everything a developer needs to provide an application to client is so ridiculous, I have no idea why this sentiment is so popular. the vitriol expressed for front end devs from the community seems out of place. Forms work without JS for the most basic baby forms. the moment you go enterprise, more is needed. which is where JS steps in, What am I missing here?

e12e 4y ago
You would make multiple form, and track state on the server side (user createdvempty/wip loan, user added assets, user reviewed and confirm loan). Probably share state between client and server via a session token (cookie). Optionally share some state via REST - eg loan ID and asset IDs in path). That said - complex forms is a typical example of when you might want to move from a web "page" to an "app".
- legopeice 4y ago
  Share state? I disagree heavily. There is no reason for the backend to know how many assets a user is trying to add to a loan, or delete, or accidentally load, or add but realize mid-way that it doesn't apply. Do you belive the backend should know about human incorrect input and track state? What if a cat steps on a keyboard? every addition to a form is a page reload and a query to the server. then the server sends a response. Which is exactly the bloat everyone seems to go on about. Im sorry but living in a world of enterprise apps, the sentiment that JS is a poor language and a bad choice is both out of place and highly de-coupled from real-world usage.
  - e12e 4y ago
    You need to share state. You might only store finished loan applications server side, but often it's nice to allow a user to pick up where they left off. Or keep a list of started, not finished applications, to hand over to sales. Etc. But sure, application state might not go in the same db/schema as completed transactions.
    - legopeice 4y ago
      Seems like a pretty good place for the browser and JS to step in? unless you want a DB full of application_partial tables?
      - e12e 4y ago
        Well, if you want to allow users to resume sessions from desktop on laptop/phone/tablet - you need to store state somewhere else. But there are different levels of state: completed transactions (application finished and submitted), partial business logic transactions (three out of five steps completed) and "app state" (field 6 of form 4 partially filled in etc). They can all be kept diffently in sync (in sync, because the browser will keep partial state via native widgets if nothing else). Even w3m keeps track of inputs in forms before submission.
        legopeice 4y ago
        Seems we are having a different discussion now about shared state instead of whether JS is necessary and capable. Over used. definitely. Obsolete and to be derided at every turn. absolutely not.
        e12e 4y ago
        The initial question (how would you create a form for handling creating multiple dependent resources without using js) - is inherently about various types of state - and if/how to share them between the client and the server. As I mentioned, I think complex business flows like these can be a great reason to go from "web page" to "web app" - precisely because it enables rich, ephemeral client state with (some) business rules close to the client. But that doesn't mean you can't do powerful things with just html/http and some form of continuations etc on the back-end.
Planktonne 4y ago
> the moment you go enterprise, more is needed. If you're employed, working at scale and need to do the complicated stuff, you're not a beginner web developer anymore. At that point, you should already understand the fundamentals and start extending on top of that.
- legopeice 4y ago
  Precisely. Good observation.

e12e 4y ago

You would make multiple form, and track state on the server side (user createdvempty/wip loan, user added assets, user reviewed and confirm loan). Probably share state between client and server via a session token (cookie). Optionally share some state via REST - eg loan ID and asset IDs in path). That said - complex forms is a typical example of when you might want to move from a web "page" to an "app".

legopeice 4y ago
Share state? I disagree heavily. There is no reason for the backend to know how many assets a user is trying to add to a loan, or delete, or accidentally load, or add but realize mid-way that it doesn't apply. Do you belive the backend should know about human incorrect input and track state? What if a cat steps on a keyboard? every addition to a form is a page reload and a query to the server. then the server sends a response. Which is exactly the bloat everyone seems to go on about. Im sorry but living in a world of enterprise apps, the sentiment that JS is a poor language and a bad choice is both out of place and highly de-coupled from real-world usage.
- e12e 4y ago
  You need to share state. You might only store finished loan applications server side, but often it's nice to allow a user to pick up where they left off. Or keep a list of started, not finished applications, to hand over to sales. Etc. But sure, application state might not go in the same db/schema as completed transactions.
  - legopeice 4y ago
    Seems like a pretty good place for the browser and JS to step in? unless you want a DB full of application_partial tables?
    - e12e 4y ago
      Well, if you want to allow users to resume sessions from desktop on laptop/phone/tablet - you need to store state somewhere else. But there are different levels of state: completed transactions (application finished and submitted), partial business logic transactions (three out of five steps completed) and "app state" (field 6 of form 4 partially filled in etc). They can all be kept diffently in sync (in sync, because the browser will keep partial state via native widgets if nothing else). Even w3m keeps track of inputs in forms before submission.
      - legopeice 4y ago
        Seems we are having a different discussion now about shared state instead of whether JS is necessary and capable. Over used. definitely. Obsolete and to be derided at every turn. absolutely not.
        e12e 4y ago
        The initial question (how would you create a form for handling creating multiple dependent resources without using js) - is inherently about various types of state - and if/how to share them between the client and the server. As I mentioned, I think complex business flows like these can be a great reason to go from "web page" to "web app" - precisely because it enables rich, ephemeral client state with (some) business rules close to the client. But that doesn't mean you can't do powerful things with just html/http and some form of continuations etc on the back-end.

Planktonne 4y ago

> the moment you go enterprise, more is needed. If you're employed, working at scale and need to do the complicated stuff, you're not a beginner web developer anymore. At that point, you should already understand the fundamentals and start extending on top of that.

legopeice 4y ago
Precisely. Good observation.