6 ms·

On one hand, the whole web stack is completely broken and insane. On the other hand, if you use the right development methodologies such as unit testing, MVC,

by dakimov 13y ago

On one hand, the whole web stack is completely broken and insane. On the other hand, if you use the right development methodologies such as unit testing, MVC, MVP, MVVM, and/or frameworks that translate statically typed or functional code to JS, the write-build-run-debug cycle is not an issue, because in general it only becomes an issue with a wrong approach to programming. This is totally the same as in non-web-programming.

scrrr 13y ago
Yeah, I also think there should be a more fundamental discussion about where the web is heading. Instead of fixing the tools perhaps one should think about a new foundation for everything. Not sure HTML etc. is it.
- Isofarro 13y ago
  I'm fairly sure that's been tried before - with XHTML2 and disappeared down some black hole never to reappear - http://www.w3.org/2004/04/webapps-cdf-ws/summary http://www.w3.org/2004/04/webapps-cdf-ws/summary . And HTML trundled along unwanted in WHATWG through those times, scorned, rejected as inadequate and not suitable. And yet, XHTML2 got closed down, everyone switched back to the HTML path. And processes involving changing web development from an environment to an output format - Google's GWT and Dart, don't seem to have gained much traction. I don't know what happened to Xanadu, either. You probably should dig into the history of Rich Internet Applications (formerly XUL, before Mozilla decided to stamp out the naming confusion with their own XML vocabulary), in the days before Ajax really stabilised and things drifted back into the browser.
  - SupremumLimit 13y ago
    I would say these approaches were still just bandages, so it makes sense they didn't catch on. GWT, for example, was a fairly nasty leaky abstraction. I don't think it removed the need to understand the rest of the stack, and it added a whole lot of its own Java inspired complexity. XHTML wasn't solving any fundamental problems either. In an ideal world, now that the web has shifted from being a bunch of linked documents to complex applications, we'd have a development stack aimed at developing applications, with sane means of specifying UI layout and behaviour, low overhead client-server comm protocols etc.

by dakimov 13y ago

scrrr 13y ago

Yeah, I also think there should be a more fundamental discussion about where the web is heading. Instead of fixing the tools perhaps one should think about a new foundation for everything. Not sure HTML etc. is it.

Isofarro 13y ago
I'm fairly sure that's been tried before - with XHTML2 and disappeared down some black hole never to reappear - http://www.w3.org/2004/04/webapps-cdf-ws/summary http://www.w3.org/2004/04/webapps-cdf-ws/summary . And HTML trundled along unwanted in WHATWG through those times, scorned, rejected as inadequate and not suitable. And yet, XHTML2 got closed down, everyone switched back to the HTML path. And processes involving changing web development from an environment to an output format - Google's GWT and Dart, don't seem to have gained much traction. I don't know what happened to Xanadu, either. You probably should dig into the history of Rich Internet Applications (formerly XUL, before Mozilla decided to stamp out the naming confusion with their own XML vocabulary), in the days before Ajax really stabilised and things drifted back into the browser.
- SupremumLimit 13y ago
  I would say these approaches were still just bandages, so it makes sense they didn't catch on. GWT, for example, was a fairly nasty leaky abstraction. I don't think it removed the need to understand the rest of the stack, and it added a whole lot of its own Java inspired complexity. XHTML wasn't solving any fundamental problems either. In an ideal world, now that the web has shifted from being a bunch of linked documents to complex applications, we'd have a development stack aimed at developing applications, with sane means of specifying UI layout and behaviour, low overhead client-server comm protocols etc.