3 ms·
> and "web applications" which are non-trivial interfaces to complex data I'm yet to see these non-trivial interfaces to data that justify megabytes of JavaScr
by dozzie 10y ago
> and "web applications" which are non-trivial interfaces to complex data
I'm yet to see these non-trivial interfaces to data that justify megabytes
of JavaScript in actual production use. There are several cases when it makes
sense (e-mail client (but not that much, and can be just fine without any JS
whatsoever), text processor or spreadsheet, chat), but those are rare.
- ng12 10y agoI write business applications for a living, and those tend to have lots of asynchronously loading data, dynamic UIs, and fancy little widgets like charts or graphs. Just because you never use them doesn't mean they don't exist.
- dozzie 10y agoYou do realize that those "fancy little widgets like charts or graphs" don't need JavaScript? We had them for dozen years before the "everything needs JavaScript" fad. OK, let's put charts and graphs aside. What do these business applications of yours do that need JavaScript and can't be equally well done traditionally, on the server side?
- ng12 10y agoI'd love to know how you'd build an interactive chart that live-updates with new data and has pan/zoom functionality without Javascript. Or how you'd asynchronously provide updates to a stream of events (e.g. Facebook) from the server-side.