4 ms·
If it is just validation a js framework would be overkill. jQuery would fit well here.
by wolco 7y ago
If it is just validation a js framework would be overkill.
jQuery would fit well here.
- dsego 7y agoYou missed the multi-page forms part. As soon as you have state of some fields affect how other fields or parts of the page display it becomes complex really quickly. There is an explosion of possible states. If you've ever seen code like this, you know why more modern js frameworks were invented: onSomethingChanged() { $('#foo').prop('disabled', true); $('#spinner').removeClass('invisible'); $('#error-1').prop('hidden', true); $('.buttons').hide(); if (value) { $('#btn-2').show(); } else { $('#btn-2').hide(); $('#btn-3').show(); } // etc ... }
- scarface74 7y agoMy favorite combination for dead simple sites is HandlebarsJS. 1. Render model from your JS object. 2. attach events 3. Change model 4. Go to step 1
- minism 7y agoYou're just describing MVC which is essentially what most frameworks contain at their core on some level.
- scarface74 7y agoI know. I use server side rendering all of the time - well at least until I got back to my safe place doing back end work. It was one project for $reasons I had to use a very light framework that I could copy paste the entire library into the page. I couldn’t depend on the device having an internet connection. I could also precompile the templates.
- im3w1l 7y agoI think he would model that as POSTing. Server side PHP would render document from scratch from the state.
- dsego 7y agoIt's silly to do a round trip to the server just to change some local UI state, right?
- manigandham 7y agoNot really, this kind of thinking is exactly what led to the client-side JS framework mess. Round trips are just fine. Browsers are smart, servers are fast, and HTML compresses well. The site you're reading right now (HN) requires a reload. Stackoverflow requires a reload. Neither are slow to use. If your page is really that complicated, then I suggest Vue or Preact which are efficient and designed to progressively enhance pages instead of rebuilding everything in JS.
- Roboprog 7y agoCompression over HTTPS can be problematic, as it makes the key easier to crack. I would like to trade out AngularJS for Vue someday, though.
- Nyandalized 7y agoConnectivity is not always available, and errors retrieving it may mean you have to re-enter everything. Being able to "navigate" the site without the dinosaur is a tremendous boon for end users. You wouldn't be able to send anything without a connection, but you could buffer it for an opportune moment. Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.
- manigandham 7y agoMost bread-and-butter sites are just fine as server-side rendered page. Large client-side frameworks reimplementing the browser and server functionality should be rare, when the situation actually calls for it. If you really need a offline site then a simple service worker is all you need to cache the pages, not a big JS app.
- winrid 7y agoOn a side note, all that complexity in the example could be managed with adding/removing a single CSS class :p
- dsego 7y agoYeah, I didn't really try to make it realistic. But I've seen very similar code, it would maybe reset inputs, calculate some results, stuff you can't really do with a single css class. T