It's just not a well designed language. Basic object comparison frequently results
in mind-blowing violations of the principle of least astonishment.
We have piled dozens of different and mutually exclusive hacks on top of the
language to support name spacing. To this day, I still stumble over the fact that
this will frequently not be pointing to what you think it is.
I'm sure you've seen sites that refuse to record their state in the URL. Oh thanks,
I didn't want to bookmark this anyway. Too often these days I can't even tab through
form fields. If for some bat-shit crazy reason you find yourself using editable
DIV elements instead of actual form inputs, please at least remember to provide
the functionality we have been using since the '80s.
Then there are willful substitutions of the developer's judgement for that of the user.
I have never actually wanted a modal window to appear. Every time I see one, I just think
"well, fuck you too". Maybe you have alt-clicked on a link somewhere
only to have the link open in the current tab instead - or perhaps not open at all.
Presumably there was a good reason to re-implement the wheel by creating your own
special thing that's text you can click on, but that is not a real
A element. NOT!
The 10th circle of hell should be for web developers who break the back button.
My pet theory is that the rise of dominance of rich client side apps is actually mostly an accident of history. Right around 2005, with the launch of Rails and Django, we had finally come up with ways to write server-side web apps that were not like sticking a fork in your eye. We finally had separation of controller and view, along with features like flash messages, session variables, and form validation, which made it easy to implement a rich interaction with state persisted between server side renders. On broadband, the server round-trips were so fast it felt like you were serving up these dynamic pages from your local machine.
But at the same time, mobile was just starting to come on. All these pages we were writing that rendered quickly on broadband absolutely sucked on mobile. No matter how fast your server was, latency was killing you on these shit early wireless networks. But we had a few years of AJAX under our belts, so we knew we could deliver the illusion of responsiveness by simply not reloading the page.
I remember trying to write an app for IE7 that was 100% rendered on the client side from a pure JSON server backend. That shit was ridiculously slow back in the day on a broadband connected PC simply because IE7 could not render a decently complicated HTML chunk into a previously rendered DOM without going out to lunch for several hundred milliseconds doing god knows what - while at the same time completely locking the UI of the browser.
Then a funny thing happened. Mobile users roundly rejected web apps. These days, you are an absolute second class citizen on mobile if you don't have a native app. Even Apple got this wrong. Their initial plan for the iPhone was to only have web apps at the platform for third-party developers. IMO, for all our progress in the last 5 years, wireless networks and phones are still shit, at least compared to where we hope they will be in 10 years. Maybe then we will finally be able to deliver write once run anywhere mobile web apps.
I'm here to tell you that you're doing a lot more work this way. Most apps can provide the same experience with about 5% of the client side code. Plus, you're slowing down your development team throughput significantly. All that extra complexity is not free. All of a sudden you have to hire people who specialize in front-end and people who specialize in back-end. It used to be that virtually all web devs could do both well.
Now if you deliver apps this way, it is absolutely critical that you serve page renders fast. With client-side apps this is not as critical, which means people have been getting lazy on this.
Besides development speed, you get a host of other benefits. Code is less complicated. I have seen over and over again in my work that UI event code tends to be the hardest to write and maintain. If it's not total spaghetti, you're doing pretty well. Don't write that category of code if you don't have to. Your app will be easier to debug; no more hunting down what view is calling what API to deliver what data to your browser in a given HTML chunk. Side note: for the love of god put model IDs and other human-readable attributes in your client-side generated DOM if you value your sanity. You also reduce the compatibility issues between browsers to relatively simple CSS differences.
Now get off my lawn!
> END RANT <
Edit: This just got posted to Hacker News. Thanks! I guess this hit a minor chord. If you want to hear more, I'm going to do a whole episode on it on my new podcast, the Software Engineering Fireside Chat. Look for it next Friday.