It is scary how most commenters here are missing the point. No, not all programming sucks. Yes, web programming sucks more than other things. No, it doesn't have to be like this. Yes, even web programming was better 10 years ago. No, I don't know how to fix it. Neither do I know exactly where we took the wrong turn.
One of my theories is this: had Sun not sued Microsoft over their extensions in JVM, MS would have kept working on their awesomely fast JVM implementation for Windows. That would make Java fast and not sucky in browsers. It would have kept Java Applets as a viable rich web app development option. Flash would have never risen. Java, being a significantly superior language to ActionScript, would have allowed us to build nice RIAs in an efficient, secure and portable way. Gmail and Google Maps would have been implemented in Java. Isometric Java. Get it? Get it? Back end and front end are written in the same language with strong typing and all that. JavaScript would have been dead by now. World would have been a better place.
I'm sorry but I beg to differ, web programming 10 years ago was a nightmare. It's much better today. It's not web programming that sucks, it's programming with others. I bet most people won't complain much if they got choose what tools they wanted and worked alone. When working with others, different ideas and opinion clash heavily. Programmers are not best known for their awesome communication and the lack of it leads to more mental strain than necessary.
The reality is that one can drive the frontend with 100% javascript no frameworks, html, css, keep things simple avoid the framework nightmare. Use typescript if the project is large enough. How come people are not doing this? Because they are not putting in the time to learn the language, it's all about learning framework. I see the same in backends, people who know rails but not ruby, laravel but not not enough php, android framework but not enough java. This is the problem.
I maintain a web-application by myself: I choose the platform and exactly which bits I wrote myself, and whre I pulled things in from other sources.
It still sucks. The target environment is undefined. In most programming problems we start with with a well defined target environment (or at least the language semantics are well defined and we quickly learn where the platform-specific hacks are).
In web programming each of the browsers is slightly different in about a hundred different ways. The main goal of using the web (presenting a platform independent UI without needing to download native code) is not entirely achievable. Instead, each year we apply slightly different hacks to go around in circles.
> In web programming each of the browsers is slightly different in about a hundred different way
Is this actually true? There are stable, well-tested shims for just about everything out there. CSS strikes me as the only tricky bit, but generally if IE8 users don't get to see an animation I don't really care.
Something largely only possible in hobby projects unfortunately.
On hobby projects I support only standards. Your browser not to spec? Not my problem. Well, it would be my problem, due to less traffic from people with broken browsers, but I don't monetize or track my traffic.
Professionally, I'm over here supporting IE8 and Safari 5 (the last version available to Windows) still. Next year we'll finally be dropping IE (all versions) so only a few more months to go.
Unfortunately if something is broken in Chrome or Firefox - I get to fix it. Then when the browser finally fixes it - I get to go fix it by removing the old fix which now breaks things. Really unproductive but I can't argue against it.
"it's not web programming that sucks, it's programming with others."
Most non-trivial systems require several contributors. 'Professional' means among other things being able to work with others.
"When working with others, different ideas and opinion clash heavily."
Sounds like herding cats. Any complex system should have a technical lead/architect who actually has the authority to say which technologies will be used. It does not mean he shouldn't discuss this with others - but the fact that there is one authority in the end simplifies things.
... and this is the problem. when you are using a library from github, you are programming with others. when they break those libraries, they are breaking your application, any bug in it creeps into your application, if the interface is poorly designed, your code will be hackish to get around it, if it's a pain to setup and configure, you have to deal with it. most programmers today are programming with others, and there's no technical lead. you grab 5 different packages, they all have different styles. In the javascript world people sometimes end up with libraries clashing over each other. This is what I mean by programming with others. :) There is no one authority in the internet. We got that with Linux, OpenBSD, Python, and Ruby and people cry so much about those "dictators"
How can programming with others be the reason, if the OP is saying they find programming for the web with others is much harder than applications development with others?
You cannot assume that the others with web programming is the same others with application programming. The result of one doesn't have to match the other.
Okay, but then how can an observer uninformed on the composition and dynamics of either group conclude that's the real reason it sucks? Unless they're slandering web developers but didn't make that clear?
it was a nightmare (because of the browser support), but it was a nightmare with a hope that it will get fixed (browsers will get better, there will be simple thin abstraction libraries added, etc).
I haven't used those much, just glanced over a system written in them. But that sounds bizarre: I thought the whole point of PHP was to be bland and mainstream. If you know how to program at all, then what is there to learn about it?
I didn't mean that as a criticism. These are all good choices for the role that PHP was intended to play, being the language that everyone writes 10 lines of for their personal website.
Java had another big problem. It couldn't interact with DOM properly.
I mean, it could. But it was terribly hackish and anyways involved Javascript.
So you had one of two options:
1. Write an HTML webpage or
2. Write an empty webpage with a large Java applet in the center, which would be function as a "virtual terminal".
Both are ugly. That's why Sun created Java Web Start (IIRC), for complicated Java applications which could be loaded from the Internet.
Perhaps Google Docs could have done something like that, but I like the current UI more than the "potential Java Google Docs". The only thing Google Docs now can't do is Cntrl-S or something like that.
Also, don't forget the real reason (existing) Java Applets died - security.
Web start has to be one of the best web technologies that almost no one ever heard of. It had most of the benefits of the web for LOB apps, and most consumer apps are probably better off not being web based in the first place.
Right, that too. For example, the amount of work that every serious web app puts into implementing some kind of hierarchical system for storing, naming and accessing objects and then allowing users to share them with each other is astonishing. If only there was a way to have the operating system provide some kind of similar abstraction to the users!
Sure, as said in other threads here -- large companies full of brilliant people can build good RIAs. Small companies full of OK people are suffering.
Java Applets security could have been solved. I'm not even sure what problem you are referring to exactly. With todays web we get insanity of XSSs, CSRF and who knows what else. The only reason these are not killing modern web development is because this hydra has too many heads.
Java had drive-by malware downloads galore. Unfortunately, Javascript isn't immune from this, probably for the same reason: to increase performance requirements, they both JIT code, which allows potential buffer overflows, etc.
This doesn't sound like the full explanation about the security problems of Java applets. It sounds more like a JIT bug. One can fix the JIT to check for out of bounds errors.
What's the real reason Java applets were insecure?
No, the security came much later, by then the ship was already abandoned. Also, in many ways, the security of Java Applets was actually better than ActionScript. For example, it could actually contain security contexts within one Applet. In ActionScript, every line of code had access to everything, which is a huge engineering flaw. Exception to this are web workers, but their usability is very low.
Sun wanted Netscape to put Java in the browser, but Netscape was already planning on making their own scripting language. Had Sun convinced Netscape otherwise, Java would have had good DOM bindings.
Sure, that's possible, but not necessary. Devs might have been smart enough to stay away from extensions. Microsoft might have been smart enough to not push it too hard. Your example of ActiveX actual supports that -- ActiveX never became super widespread, remaining a niche thing. Also keep in mind that this was only few years before OS X was released bringing the 2nd consumer desktop OS back onto the market.
If you can save a week's work and make your site work on 97% of computers, or spend another week to get it to 99%, what would you do?
And in truth, Mozilla/Opera/other HTML browsers had around 10 percent of marketshare even during the heydays of IE6's reign, and yet plenty of websites only worked on IE6.
Would programmers care about those five percent of Mac users?
> Java, being a significantly superior language to ActionScript
ActionScript 3 was all right. A bit too listener-heavy but a mature, reliable, comprehensible language, and arguably lighter and more approachable than Java. Had Microsoft (among others) not nobbled it back in 2008, we might be using it as the next generation of JavaScript (ES4) by now.
ActionScript was all right, I don't disagree. Especially compared to JavaScript. But i think it would have been nice to have the same language on FE and BE.
I'm saying there was hope. I remember 2005. IE was getting better. Chrome/Firefox/Opera were close enough, once I got one of them working i barely had to do anything. So it was essentially targeting 2 platforms (IE and non-IE) and hoping IE would get fixed. Today that problem is largely solved, but we have created an unmanageable lasagna of complexity in the process.
