3 ms·
Reminds of classic ASP, which could actually run JScript on the client as well as the server. However, eventually, this technique results in a spaghetti of UI,
by nreece 19y ago
Reminds of classic ASP, which could actually run JScript on the client as well as the server. However, eventually, this technique results in a spaghetti of UI, logic and DB code - all in one place. Ideally, these tiers should not be tightly-coupled.
- LogicHoleFlaw 19y agoIf we can keep just the UI in the Jaxer<->Browser world with logic and DB elsewhere, then this problem may be alleviated. I think that directly manipulating the DOM on the server, rather than working with raw HTML is the big win. Having the client and the server seeing eye-to-eye on the logical representation of the document being transmitted removes one of the many impedance mismatches in web programming.
- tx 19y agoAgreed. It also reminds me of current ASP.NET where you can manipulate DOM (as long as it's marked with runat=server) as well, only with ASP.NET you also get super-powers of .NET runtime. To me it sounds like a bunch of browser/JavaScript dudes are trying to write server-side software, being unaware of how it must be properly written. Seeing SQL surrounded by HTML tags is so late 90s... The real gains, however, will happen when we'll be able to do it exactly backwards: run typical server-side code (blessed with rich runtime) inside of the browser. Browser's DOM (runtime) sucks. This is why there are so many browser-side runtimes being developed right now: Flex/Silerlight/JavaFX. Aptana got it wrong.