4 ms·
What's old is new again. My first front-end role was building web applications wayyyyy back in 1999. Everything was done with "Vanilla" JS, including fancy st
by fatnoah 3y ago
What's old is new again. My first front-end role was building web applications wayyyyy back in 1999. Everything was done with "Vanilla" JS, including fancy stuff like drag and drop in a treeview, click to edit, building what effectively was a single page app, etc. etc. The hardest part was negotiating the differences between Netscape and Internet Explorer.
- aatd86 3y agoHow was the state and its mutations managed? Why does it seem that we don't know how to do these things anymore? ;]
- fatnoah 3y agoIn general, the goal was to manage as little state as possible, so anything that was a one-off change, such as changing a single field, changing a node parent, etc. resulted in an async server round trip. This was done to reduce JS complexity (no jQuery or equivalent, so we had to maintain separate code for IE and Netscape) and to ensure validation was consistent. For more form-oriented activities, we used a more traditional form post & page refresh. At the time, XML was the hotness, so all of the server back end APIs accepted and responded with XML, so when we did actually want to manage state, we did it through modification of the XML representation of the data the user was working with.