A colleague, who freely admits never having tried web development, asked me to recommend a book to help him learn Javascript. In the course of the conversation, it came out that I’m a LAMP consultant. He didn’t buy it.
(paraphrased as earnestly as I can remember)
“You wouldn’t need a consultant for the web, since it’s all quite trivial. In the case of Javascript, I just need to learn the syntax and I’ll be done. Web programming is basically keyboarding compared to my area: Multi-Threading. There, the programming is real and problems are incredibly hard, enough so you would actually need a real consultant to know what you were doing.”
He had me. I don’t know much about multi-threading. What is the real difference, if any? Is my industry part of a massive farce?
Leaving aside that Javascript is just a part of the client-side, I tend to view the server-side as massively multithreaded. But the big difference is that all the hard problems in our arena have been solved! The webserver(s) take care of creating threads, and data is shared via some shared storage mechanism (database, shared cache, session stores, you get the idea).
If your friend thinks multi-threading is hard, it's because his platform doesn't provide him with a sufficient abstraction.
Web programming trivial? Hardly. Having done both web and application development (including multi-threading) I can say with some assurance that while the two are patently different, one is not easier than the other. For starters ask him how hard multi-threading would be if he had to interact with threads differently depending on whether his application was running on an Intel CPU or an AMD CPU. He now has a SMALL idea of the headache that is coding a website that is fully functional on the plethora of browsers users may have. There is also the matter of server side web development. Depending on your platform of choice and how big of a web application you are writing, the effort to write a web application is very similar to what you would expend writing a desktop application. The main, and usually comparitively small, difference coming in presentation. Let him try to code the next eBay and see how "trivial" it is. And if he's not interested in anything that in depth, show him how easy it is to write "Hello World" in his language of choice and point out that most languages only seem as complex as what you are trying to accomplish with them.
With all due respect, your friend sounds a bit loopy. Apparently he believes that Javascript is just another markup language, or thinks it's something safe and tame. I believe this is a leftover view from back when web designers were just banging out HTML and calling themselves developers.
I do real time work, including drivers and game development, and I've known many a web developer with skills that made me envious. The amount of skill required looks to be par with any other kind of mainstream programming, but you guys have the added pain of every browser having its own nasty and non-standard surprises.
It sounds like your friend may be confusing marking up simple narrative documents with developing web applications.
First, some awareness of multi-threading is required (if you are interacting with finite resources or other systems), making web app dev something of a superset of MT dev. Add to this the complications of maintaining statefulness, the back/forward/reload buttons, and guarding against malicious users of a system that must remain open.
Second, if MT API implementations were completely unreliable, to the point that 84% of installations were missing significant functionality, and every method call needed to be tested for support before each call to it (and sometimes tested afterward to make sure that nothing unexpected happened), MT dev would be closer to web app dev.
Third, MT has no UI or nav-architectural concerns. If you don't have to worry about users, your job is far easier.
Finally, how many independant systems/layers does your friend need to worry about? Web apps include an (X)HTML processor, CSS processor, JavaScript/ECMAScript/DOM processor, and that's just on the client tier. They also need to be familiar with some HTTP server platform like Apache or IIS, with some development language/platform like PHP, Perl, Python, Classic ASP, ASP.NET, Java, etc. (usually more than a couple) and their associated libraries and datatype limits. Web engineering also requires knowledge of at least one dialect of SQL (of course they're all different, too), and database design and optimization. It also pays to know the Ajax/Atlas, MIME types and extensions, RSS/Atom, page layout, Flash and basic graphic design, regular expressions, image optimization, HTTP(S), internationalization issues, ODBC or DBI usage, CMS software, screen readers/color blindness and other accessibility issues, XML, XSLT, SOAP, security and encryption basics, niche formats like iCal, Unicode, codes for languages and countries, various standards like ISO8601, browser extension coding, and networking basics. Keep in mind, too, that most of these are moving targets.
Multithreaded programming in C/C++ is definitely harder than JavaScript.
But web development ain't just JavaScript, and it definitely ain't trivial. Web development is hard because of the alphabet soup of stuff you've gotta know to be good at it-- JavaScript, HTML, CSS and PHP just to start. The learning curve is much less steep than something like multithreading (you can't be a novice and put together a functional multithreaded app-- it will crash and burn), but there's probably more to learn and keep track of.
Your friend is in for a very nasty surprise. In his world, there is only one way in which his code can be executed, and as long as he is well-versed in that way, understands to problem correctly, and makes no mistakes, his code will always run. Ah, I pine for the days when I used to program exclusively in a high-level compiled language for a single platform. Life was easy then.
Your colleague thinks he's going to basically read the javascript spec and then be able to program in it. You should be laughing in his face. When he gets wind of all of the exceptions and unexpected, undocumented behaviour on all the various browsers he needs to code for, he'll start to get really frustrated and wonder whether the web was designed by an idiot savant in between bouts of counting spilled toothpicks.
When he realises that he's going to have to use the trial-and-error method he normally reserves for the most difficult debugging just to figure out what programming statements various web browsers will accept, he'll start to froth at the mouth. Just a little.
Finally, when it dawns on him that the spec is essentially useless and most javascript programmers use Google as their spec, he'll conclude the lot of them are insane and he'll probably retreat into PHP to lick his wounds in a controlled environment.
At which point you can give him a Cheshire grin and say, 'Y'know, this kind of loose collection of decentralised bits of knowledge that you won't find concentrated in any definitive manual is exactly the sort of territory that is a lot easier to navigate with the help of a consultant.'
The perceived simplicity of web programming is source of great pain and frustration to coders, program managers and customers alike.
The difficulties encountered are not quite the same as in system-level programming, but getting it right can be quite hard nonetheless. And ususally the problems all pop up after the product is deemed ready to go.
Random cases in point:
- javascript is easy, but using it for DOM is a huge pain in the ****. Every single broser out there is different. Why did we have to wait until mozilla 1.7 (or such) to get a real debugger? And I bet most javascript coders do not even use one today
- languages to be mastered are many: asp/java/php + css + html + javascript
- css is hard, mostly because every browser does it different
- instead of multithreading we have server-side vs. client-side execution, PLUS every single request has to checked for validity and consistency PLUS the user can open up as many browser windows as he wants at the same time. How many web apps do you know that can consistently track user state in such a situation?
- a lot of people (coders?) do not grok http at all, and break all assumptions of the protocol. All is fine on their intranet workstation, but as soon as the app is on a public server and the xss/sql injection deluge pours in, scalability problems grind the server to a halt and extreme latency has customers screaming bloody murder
Programmers often think that the syntax of something they all need to know. Actual practice, however, develops wisdom and experience. Given someone who just knows the syntax of Javascript and someone who has written cross browser applications using Ajax, I know which one will probably get the job done. Problem-domain expertise is much more important than language syntax.
It's a common fallacy for people who think they are smart to think that smarts alone is all they need to do something different. Multi-threading seems to be an easier domain to me when set next to the chaos of browsers, javascript implementations, and whatnot. I've learned not to judge something I haven't done yet until I've tried it myself.
Hello, I'm that colleague of Jonathan's who has apparently managed to ruffle some feathers here :-) . Going through the comments I couldnt help but notice that most of the difficulties cited here in web development seem to come from non consistent implementations. Is that complexity a sign of genuinely hard problems or is it an artifact of accidental complexity created through non standard implementations in browsers. I agree that developing the next ebay would require incredible effort, but How much of ebay is the 'web' part and how much of it is the 'backend' stuff .. I admit I do not know but the fact that we, the "system trolls" are still in business is an indicator. And yes multithreading does has its share of accidental complexity (windows has detached threads by default, Linux dosent, VxWorks dosent know what is a detached thread). In addition we also have the inherent 'mythical beasts' like race conditions, deadlocks, priority inversion etc which are there regardless of how good and standards compliant your threads implementation is. I certainly didnt mean to imply that web development was trivial, just that It should be possible to pick it up and do a reasonable job given effort. Cheers.. Hope the system trolls and the webmen can unite and live in harmony ever after :-)
In fact, it's so trivial that nobody smart will work on it, so it will remain forever unfinished, riddled with silly incompatibilities and bizarre conventions, and therefore hard to do in many detailed ways -- all because it's so obviously trivial, right Arunabha? As for the complexity of multi-threading, are there really any open problems? Isn't it all just engineering, now that we have all the basic theories (mutex, wait-freedom, temporal-logic model checkers to automate validation/verification), the remaining work looks pretty trivial to me. The mythical beasts you mention are old war-horse topics, for which there is ample literature showing how it can be done. The details take work, of course, but that seems rather like .. like .. trivia!
If web development were only about Javascript syntax, he might have a point. And just because a problem is expressed in C vs CSS doesn't make it harder. Have him try to come up with a CSS Zen Garden design and we'll see how long it takes. I bet I could teach a Javascript all about multi-threading, deadlocks, race conditions, and synchronization faster than a fellow programmer could learn to become a designer.
I don't think that "browsers are different" gets at the root of the problem. One of the reasons why the web is such a complex medium is because it's one in which the consumers of information, not the producers, are the ones ultimately in control of how they get that information -- and often, the producers and consumers end up being the same people. Suppose that right now, all browser implementations were consistent (and all feed aggregator implementations, and all messaging system implementations, and all mail reader implementations -- don't forget that these can all be related to web programming, too). If that were the case today, then tomorrow some people would decide they didn't like it that way and implement it their own way -- as well they should! That kind of thing flourishes at every level of web development, and everywhere open standards are found.
A huge part of the work of being a web developer is staying on top of the current state of the art and experimentation, because it changes so fast. We're always going to be trying to figure out how best to leverage the medium, because the medium is always evolving and growing in complexity. That's one reason why I think web development is nontrivial.
To my mind, "web" development is only going to get more challenging and interesting, with it becomming even more of an intersection between differing areas used seperatly before. (for example many graphics designers are competent programmers these days, and know a bit about how things are stored away in databases.) Many new "applications" are not written as a client side executable, but as interactive content served through the browser. This served content often hides intercomunicating systems behind the scenes.
I am not a web developer, but find my self having to write applications or services that are ultimatly used from a browser somewhere. web development is challenging in that it needs a broad understanding of many technologies/tools/standards/concepts to bring it all together in some sort of web system. You can't just know javascript. You can't just do the graphics and the style. You can't just do the backed services/batches. You have to have you area of expertise and then some pretty good knowledge of the rest so you can work with the other people. Just what I think. eg: google has a whole range of tools used online, but the components of those systems cover almost every industry in IT, just to make applications that are used online. Not good at explaing things, i just mean to say web development is a broad term, but it is one of the most exciting and challenging around.
Arunabha is right. Simply because you have to work out differences between browser implementations does not mean browser programming is 'hard'. That's a poor choice of words anyway. Complex is much better. Browser programming is complex not because it's difficult to comprehend conceptually, but because you have memorize so many mundance aspects of the browser. It's absurd.
Truly creative applications are built because the developer is freed from the mundane and allowed to think about the solution without being bogged down by issues that should have been set a long time ago.
i just want to know why programming is becoming an accidental complexity?
Your friend thinks web development is easy; therefor, your friend is not that brite. Your friend can code multi-threaded applications; therefor, multi-threaded coding is not that difficult.
what are the causes of accidental complexity? and how can it be solved?
Oh, so naive! Tell him to try a multi-threaded, web application for multiple target operating systems and browsers with multiple layers of security and a multiple layered architecture. Then tell him that the web application (written in HTML, JavaScript and CSS) should have the look-n-feel of a traditional desktop appliation (cascading pull-down menus, draggable dialogs, midi enabled) and have little to no lag, or down time. See where he can start. Tell him that there needs to be a clean difference between the business logic and the presentation code, so that different presentation technology types may be easily switched out (ie the next release will target mobile devices and allow uses to work off-line).
If one aspect of some technology is trivial, then all aspects are trivial. Only ignorant people make such blatant statements, especially when they are not the expert in such a field.
I made few sites with traffic over 100M hits per day and web development IS (at least at this level) simple. Just sit and write it. Nothing you must think of very hard.