5 ms·

An even better question is "Why does it take at least four different languages for database-backed web applications, and why should developing on the web be so

by Jarred 16y ago

An even better question is "Why does it take at least four different languages for database-backed web applications, and why should developing on the web be so much more of a hassle than on the desktop?

phoboslab 16y ago
You can use JavaScript client side in the browser (duh) as well as on the server (e.g. with NodeJS[1]) and your database (e.g. with CouchDB[2]). The only other languages you need are HTML and CSS. That makes 3, not 4 ;) [1] http://nodejs.org/ http://nodejs.org/ [2] http://couchdb.apache.org/ http://couchdb.apache.org/
- flomo 16y ago
  Aside from recent developments like NodeJS, the lack of interest in JavaScript as a server-side language is really weird. Both Microsoft and Netscape had JavaScript server scripting back in the 1990s, but people instead glommed onto ad-hoc languages written from scratch (PHP) or plucked others out of complete obscurity (Ruby) and made them successful. I can't help to think that history would have been completely different if someone had created an Apache mod_js 10 years ago.
  - olavk 16y ago
    JavaScript is all we have on the client side, but on the server you can choose the best tool for the job. Languages like Ruby and Python are basically supersets of the semantics of JavaScript, but with many more features and large standard libraries. And these languages evolve, while JavaScript have been basically frozen for a decade. The server side language have well-tested libraries for working with the file system, databases and so on. JavaScript is a nice, minimal language, but a bunch of other languages are just better when you are not constrained by the browser. Besides, the benefit of having the same language on client and server might not be so great. Sure it looks nicer, but the programming model on client and server is quite different anyway. Node.js is interesting. I suspect the users will soon want some syntactic sugar for dealing with asynchronicity (something like the new "await" keyword in C#). This is also neede on the client side, but much harder to get support for. But if they extend JS on the server side, does it make sense to compile down to vanilla JS rather that just forking the language?
- BerislavLopac 16y ago
  Actually, you don't even need CSS, all you need is HTML. So it comes down to two (any server-side language, basically, plus HTML), one of which is not even a programming language.
bad_user 16y ago
Why is web development much more of a hassle than on the desktop? Have you seriously tried developing for the desktop? What desktop? The one that has 90% market share and a dozen of GUI-toolkits available, including 3 official ones? Or was your app cross-platform? What GUI-toolkit have you used?
scrod 16y ago
Probably because the web isn't actually an application platform at all, but is still fundamentally a medium for displaying static hyperlinked content on top of which has been piled an increasingly absurd series of hacks (forms + CGI, Cookies, Plugins, JavaScript, XMLHttpRequest, etc.), each in order to solve a different, unrelated problem. And so we then have to write "web frameworks" to smear the incongruities of these various functionality-hooks into an end-to-end system just to enable tolerable development methodologies. If you want to make developing applications easier, then it will always be better to start with a platform that has actually been architected toward those ends from the beginning.
- cageface 16y ago
  I can't find the words to express how much happier I am with to be working again on a platform (iOS) that was designed from the ground up to build rich UIs. HTML apps are such a grotesque heap of hacks in comparison.
  - nekoZonbi 16y ago
    Excellent point. Thats the same experience I had when moved to the flash platform, some years back. Now that I am coming back to html-javascript, i can help but feel frustrated by the mess that is html app development. My dream for the web platform, would be that the committees would create some kind of underlying bytecode and basic graphic primitives. On top of which different programming languages and graphic Apis could be implemented. Then, to develop hyperlinked documents, you can use an hyperlinked document oriented API. To develop complex UI, you can use a complex UI oriented API. Maybe the web is now near that goal. Javascript could be the bytecode. And the DOM (wich I hate with passion) could be replaced by a GUI toolkit build on top of the html canvas. I would love to work on that, if I had time available.
- bad_user 16y ago
  It is funny how people complain about web apps, but then the more complex a desktop app it is, the more the UI starts resembling a web application running on top of an embedded web browser. Also, quick questions -- what other platform has a nearly 100% market penetration rate and how does that compare to the iPhone's Cocoa? AND, with the iPhone's Cocoa you're not even allowed to distribute or update your app, without going through iTunes, both of which have been problems far worse than whatever any regular web stack has caused me. Bitching about how web development sucks is NOT seeing the forest from the trees, because if you think about what web development enables, there is absolutely NO other alternative, and each of those little annoyances have a good reason for being there. And even though we could do with less cross-browser compatibility issues, I think I don't have to mention the shithole you're entering when doing cross-platform desktop UIs.
roel_v 16y ago
"and why should developing on the web be so much more of a hassle than on the desktop?" I guess with this you're implying that writing web software is harder than writing desktop apps, and to that I say 'LOL'. Even when one restricts himself to one platform (the easiest to develop for when you make some sacrifices - Windows), it's still a lot more work to get a 'real' application developed there than on the web. You need to include the whole cycle - running on various versions of the OS, application installation and updates, data backup etc. Believe me, the front end of web apps (and even the simple part of the backend, i.e. the parts without high scaling etc) are quite easy and high-level compared to the alternatives on the desktop.
- cageface 16y ago
  Believe me, the front end of web apps (and even the simple part of the backend, i.e. the parts without high scaling etc) are quite easy and high-level compared to the alternatives on the desktop. I've done plenty of work on both sides and this is only true if you're developing the kind of app that looks and acts like a fancy web page.
  - roel_v 16y ago
    You mean "the kind of web app" or "the kind of desktop app"? Native desktop apps are usually very tedious to develop, even with high-level tools like Visual Basic. Even for simple CRUD apps, the amount of layouting you need to do, input validation etc; all of those rote tasks are much more automated in web frameworks than they ever were in desktop development tools. The kind of things you can do with a few lines of jQuery in terms of UI manipulation are miles beyond what was even reasonably possible (meaning, wouldn't take weeks of work) in desktop applications.
    - cageface 16y ago
      Sure, CRUD apps should almost always be web apps. If you want a richer UI or need to do any serious local computation the web stack is a poor choice. The entire reason I've gone back to native apps after 10+ years of web dev is that I find the kinds of apps well suited for the web to generally be very boring.

by Jarred 16y ago

phoboslab 16y ago

You can use JavaScript client side in the browser (duh) as well as on the server (e.g. with NodeJS[1]) and your database (e.g. with CouchDB[2]). The only other languages you need are HTML and CSS. That makes 3, not 4 ;) [1] http://nodejs.org/ http://nodejs.org/ [2] http://couchdb.apache.org/ http://couchdb.apache.org/

flomo 16y ago
Aside from recent developments like NodeJS, the lack of interest in JavaScript as a server-side language is really weird. Both Microsoft and Netscape had JavaScript server scripting back in the 1990s, but people instead glommed onto ad-hoc languages written from scratch (PHP) or plucked others out of complete obscurity (Ruby) and made them successful. I can't help to think that history would have been completely different if someone had created an Apache mod_js 10 years ago.
- olavk 16y ago
  JavaScript is all we have on the client side, but on the server you can choose the best tool for the job. Languages like Ruby and Python are basically supersets of the semantics of JavaScript, but with many more features and large standard libraries. And these languages evolve, while JavaScript have been basically frozen for a decade. The server side language have well-tested libraries for working with the file system, databases and so on. JavaScript is a nice, minimal language, but a bunch of other languages are just better when you are not constrained by the browser. Besides, the benefit of having the same language on client and server might not be so great. Sure it looks nicer, but the programming model on client and server is quite different anyway. Node.js is interesting. I suspect the users will soon want some syntactic sugar for dealing with asynchronicity (something like the new "await" keyword in C#). This is also neede on the client side, but much harder to get support for. But if they extend JS on the server side, does it make sense to compile down to vanilla JS rather that just forking the language?
BerislavLopac 16y ago
Actually, you don't even need CSS, all you need is HTML. So it comes down to two (any server-side language, basically, plus HTML), one of which is not even a programming language.

bad_user 16y ago

Why is web development much more of a hassle than on the desktop? Have you seriously tried developing for the desktop? What desktop? The one that has 90% market share and a dozen of GUI-toolkits available, including 3 official ones? Or was your app cross-platform? What GUI-toolkit have you used?

scrod 16y ago

Probably because the web isn't actually an application platform at all, but is still fundamentally a medium for displaying static hyperlinked content on top of which has been piled an increasingly absurd series of hacks (forms + CGI, Cookies, Plugins, JavaScript, XMLHttpRequest, etc.), each in order to solve a different, unrelated problem. And so we then have to write "web frameworks" to smear the incongruities of these various functionality-hooks into an end-to-end system just to enable tolerable development methodologies. If you want to make developing applications easier, then it will always be better to start with a platform that has actually been architected toward those ends from the beginning.

cageface 16y ago
I can't find the words to express how much happier I am with to be working again on a platform (iOS) that was designed from the ground up to build rich UIs. HTML apps are such a grotesque heap of hacks in comparison.
- nekoZonbi 16y ago
  Excellent point. Thats the same experience I had when moved to the flash platform, some years back. Now that I am coming back to html-javascript, i can help but feel frustrated by the mess that is html app development. My dream for the web platform, would be that the committees would create some kind of underlying bytecode and basic graphic primitives. On top of which different programming languages and graphic Apis could be implemented. Then, to develop hyperlinked documents, you can use an hyperlinked document oriented API. To develop complex UI, you can use a complex UI oriented API. Maybe the web is now near that goal. Javascript could be the bytecode. And the DOM (wich I hate with passion) could be replaced by a GUI toolkit build on top of the html canvas. I would love to work on that, if I had time available.
bad_user 16y ago
It is funny how people complain about web apps, but then the more complex a desktop app it is, the more the UI starts resembling a web application running on top of an embedded web browser. Also, quick questions -- what other platform has a nearly 100% market penetration rate and how does that compare to the iPhone's Cocoa? AND, with the iPhone's Cocoa you're not even allowed to distribute or update your app, without going through iTunes, both of which have been problems far worse than whatever any regular web stack has caused me. Bitching about how web development sucks is NOT seeing the forest from the trees, because if you think about what web development enables, there is absolutely NO other alternative, and each of those little annoyances have a good reason for being there. And even though we could do with less cross-browser compatibility issues, I think I don't have to mention the shithole you're entering when doing cross-platform desktop UIs.

roel_v 16y ago

"and why should developing on the web be so much more of a hassle than on the desktop?" I guess with this you're implying that writing web software is harder than writing desktop apps, and to that I say 'LOL'. Even when one restricts himself to one platform (the easiest to develop for when you make some sacrifices - Windows), it's still a lot more work to get a 'real' application developed there than on the web. You need to include the whole cycle - running on various versions of the OS, application installation and updates, data backup etc. Believe me, the front end of web apps (and even the simple part of the backend, i.e. the parts without high scaling etc) are quite easy and high-level compared to the alternatives on the desktop.

cageface 16y ago
Believe me, the front end of web apps (and even the simple part of the backend, i.e. the parts without high scaling etc) are quite easy and high-level compared to the alternatives on the desktop. I've done plenty of work on both sides and this is only true if you're developing the kind of app that looks and acts like a fancy web page.
- roel_v 16y ago
  You mean "the kind of web app" or "the kind of desktop app"? Native desktop apps are usually very tedious to develop, even with high-level tools like Visual Basic. Even for simple CRUD apps, the amount of layouting you need to do, input validation etc; all of those rote tasks are much more automated in web frameworks than they ever were in desktop development tools. The kind of things you can do with a few lines of jQuery in terms of UI manipulation are miles beyond what was even reasonably possible (meaning, wouldn't take weeks of work) in desktop applications.
  - cageface 16y ago
    Sure, CRUD apps should almost always be web apps. If you want a richer UI or need to do any serious local computation the web stack is a poor choice. The entire reason I've gone back to native apps after 10+ years of web dev is that I find the kinds of apps well suited for the web to generally be very boring.