Do Web Developers Ever Learn?
bitroar.posterous.com
bitroar.posterous.com
No, the majority didn't. Bad developers did stuff like this, and some are probably still using the same tricks right now.
The majority realised how stupid it was to do so, and therefore didn't create links like this.
I've seen some crazily bad website code in my time, include sites outputting their HTML using nothing but hard-coded document.write() calls. That doesn't mean the majority of developers were following suit.
There's always been a divide between what developers encourage, and what clients ask for and want. This is one of the better arguments FOR developers creating javascript-heavy single page sites (for themselves, or demos)... if they had to rely on their clients they'd probably be years behind the curve.
1. Forms that auto change fields
99% of the time using a computer tab goes to the next field so it's muscle memory to press tab after filling out each field. Then some dumb add web dev decides that for zip code, once I enter 5 digits he'll automatically move me to the next field. This has at least 2 problems. Either my muscle memory had already moved me one field too far or, I made a mistake on one of the last digits and backspace does nothing because it's been moved to the wrong field.
2. Credit card or phone number fields that require a certain format
Many sites insist on 1111222233334444 or 1112223333. Entering 1111 2222 3333 4444 or 1111-2222-3333-4444 and they complain. Just filter out the digits on submit or on the server! Stop making me do things the computer can do so easily.
3. Auto formatting fields
Stop trying to be clever with a form that shows one field that looks like (111)223-3333 but doesn't let me type the (, ), or -. Apply #2 above. Stop messing up my keyboard usage by making it different than every place else I type.
4. Forms that ask for city, state and zip code
Ask for the zipcode first and then fill in the city and state (the let the user change them)
What are your web dev pet peeves?
addresses are strange. humans think of addresses in little-endian terms because to them the rest is implicit, while computers and filtering works better big-endian where no assumptions can be made in advance. meh.
No, this is culture-specific. In Russia, postal addresses are written exactly the opposite ("big endian") way.
This was true a decade ago and may have changed, but that industry can be pretty slow to update.
That would require way too much typing.
How about we just say: Adobe Flash. Worst thing to ever happen to the web. It was the MIME killer. And it was all for nothing. Adobe themselves killed it, it was so bad.
Of course, web devs _loved_ it.
Remember, swf means small web file.
Designers and game devs loved Flash, but web devs hate(d) it. The only cool thing about it from a web dev perspective was Actionscript, but this was before Javascript was cool. You could also do long polling with it, but not many people did – anyway, this was really something that game devs loved, not web devs.
"Swf" is for ShockWave Flash; swfs are notoriously large. One of the hallmark of Flash files was the ubiquitous loading screen.
For example, I was using a payment form recently. There was a <select> list for choosing my country, now I like to use keyboard as much as possible so I filled out the form by tabbing between the fields.
The normal way a select field should work is that arrow keys navigate the list and enter selects the current value.
Unfortunately the developer had hooked the enter key to submit the entire form.
Took my about 5 attempts to make the payment because I kept instinctively hitting enter to select the country before the form was completed.
Take my site: https://circleci.com. Doesn't work in IE8 or less, and it has some bugs. But when you click a new page, it happens immediately. Properly immediately.
Inside the app, when you click a new page, it takes 1 AJAX request to load. Not 50 JS/CSS/img assets. No white flash. Just 1 click and it loads instantly.
Now, that's not to say that the majority of sites like this couldn't be done better. They could, and so could we. We need to sort out our SEO story for a start. But we made a conscious decision to do this because it makes sites fast, and much easier to write.
(PS: like the sound of hacking on dev tools in clojure? We're hiring!)
That's why I personally use the strategy of rendering server-side only upon initial load, then hooking in client-side routing/templating libraries afterwards. This solves the issue of search engine visibility and client JS support in one fell swoop. (Mustache templates are great in this regard since there's libraries supplied for most languages.)
By the way, just a nitpick: your site seems to have a empty margin to the right, which creates a horizontal scrollbar. I'm using Chrome Version 21.0.1180.89 on OSX.
We have a very pragmatic attitude. When people complain, we start to prioritize it (thanks for the bug report/nitpick!). If no-one complains, it can't be important. We haven't heard any complaints from non-JS users yet :)
Is there a name for this strategy? How can I read more about it?
But I think the real issue at hand isn't about being single-page, it's about using single-pageness as an excuse for ignoring certain usability and architectural issues.
No white flash. Just 1 click and it loads instantly.
Unless you're using IE9.
Also, I couldn't click any of the top links on my Galaxy S.
> But I think the real issue at hand isn't about being single-page, it's about using single-pageness as an excuse for ignoring certain usability and architectural issues.
Agreed. Funnily enough the architectural issues are easier with one page apps, IMO. You just expose a REST API, do your asset caching, and don't need any HTML caching at all!
> Unless you're using IE9. Also, I couldn't click any of the top links on my Galaxy S.
Thanks for the reports. I think those are orthogonal from the one-page JS app though, and are more due to building a PaaS with 2 people. We'll fix it though!
Let's say I want to build a new search engine. How do I crawl your website without having Google-esque budget? More importantly, if all websites were built like that, how would anyone could build a new search engine?
That's also architecture. How do things interact? What is possible and what is not? What kind of things would happen if technology became popular?
The real issue here is not that the page is not crawlable right now. I know there ways of addressing this. The issue is that it's not semantic and that you need to do extra work (separate from normal development) for search engines.
If you were to create a new search engine, and it didn't take into account one-page-apps, I'd say you've built the wrong architecture too.
Finally, it's not that we don't have the time, it's that we dont have the time _right now_. Web apps suddenly became hard in the last 3 years - people expect a lot more than they used to. But our priorities must be to deliver the kind of experience that customers desire. Technology should be our servant, not our master.
I care about how my customers experience Circle.
If your customers care about privacy and security and browse with JavaScript disabled by default, they will be annoyed. If they have disabilities and use a screen reader, they're likely screwed. If they get lost in your docs and decide to use "site:circleci.com" query to find the page they need, they will get nothing. If they would want to use a mini-crawler to download your docs for local usage, they will get nothing.
That is user experience, and those things are objective. They either work or not. On the other hand, performance gains and development time gains of single-page apps are -- debatable.
If you were to create a new search engine, and it didn't take into account one-page-apps, I'd say you've built the wrong architecture too.
There is no reliable way to build a search engine that would crawl through websites created mostly in an imperative language. Even unreliable ways to do that are complicated enough that Google and Microsoft fail miserably at them.
I'm on Chrome 21.0.1180.89 on OSX Lion BTW.
The "Continuous Integration for Web Apps" flash is due to our Kissmetrics client-side A/B testing. An interesting point is that if we were doing server side A/B testing, we probably wouldn't see that. On the other hand, once I saw that for the first time, I realized it drew my eye to it, and figured it's not a bad thing. But maybe I'm compensating.
PushState, for example, is not a bandaid, and for those not-so-modern browsers there are hashtags (let's be frank: 99.9% of users don't care about how beautiful or ugly their URIs are and even less about one particular character).
In many cases such as WYSIWYG editors, which he mentions, Javascript is the only way (HN users might prefer Markdown, but for most average users, that's already too complicated). New HTML5 input types are awesome, but they are in this case the advanced fragile technologies that currently lack a broad support base.
I particularly disagree on the last two points: These days, Javascript and CSS is minified, sprites are used on basically all popular sites and content is gzipped. Many people even use a CDN for their JS frameworks. Loading time optimization is a topic more important than ever before. The same goes for mobile versions: I see a lot of people even offering a mobile-optimized version of their portfolio.
He is certainly right saying that these aspects are all very important, but I don't really see the lack thereof in practice. Any examples, perhaps?
As someone who is constantly not using the features I'm learning about due to IE7/8, I mess with things that definitely won't work on anything other than Chrome Canary. Why? Because it's a fun and brave new frontier.
I really think you can't complain about the web being NOT perfect. It's full of dinosaurs and people are still running on oil. And besides, this newfangled green revolution has a ton of kinks we need to take care of before we can make the switch.
Transitional. The web is in a state of flux always.
But PushState is great. I think some clarification is needed from the author to support this claim.
Keep in mind that using the history API (push|replace)State is not so much about making the URL pretty as it is about page refresh semantics.
With a hashtag the page refresh loading the correct content requires at least one more trip to the server to load the content represented by the hash and relies completely on your JavaScript not breaking.
With a url "fixed" by (push|replace)State the server can respond directly with the content speeding up the response time and removing a point of failure.
[Also, would that mean that I would need to maintain a list of every single possible route in the whole site?]
In the sense of overall web architecture, it is a bandaid. You're using an imperative language to change the state of the page, and then you're using imperative language to fake moving from one page to the next. If you want the whole things to be crawlable, you also need to have extra code that generates the new "page" as if it wasn't a result of client-side manipulations.
Did you ever ask yourself what would it take to go the opposite way and efficiently represent client-state changes by page navigation? Not that much, especially which proper technologies built into the browser.
In many cases such as WYSIWYG editors, which he mentions, Javascript is the only way
There is nothing wrong with using WYSIWYG editors written in JavaScript. However, they shouldn't interfere with standard functionality, such as spell-checking.
It wouldn't hurt if such a popular control was built into browsers either, rather then re-implemented hundreds of times.
I particularly disagree on the last two points: These days, Javascript and CSS is minified, sprites are used on basically all popular sites and content is gzipped.
That doesn't stop people from writing inefficient JS code or simply loading too much stuff. Open this with FireBug, for example: http://www.smashingmagazine.com/ . That is one of the leading websites on webdesign. What is there to expect from corporate pages and various product (i.e. movie or game) websites?
Try browsing on Kindle (not Fire) to see which websites really are efficient and which ones aren't.
Yes, if I go to a Web Design commuinity like /r/web_design on Reddit I'll see pages of unusable web pages with hundreds of HTTP requests, 2-8MB of assets and "support" for legacy browsers using Modernizr. Some people view this as the future, but I view it as a site built by an entry-level developer that will be unusable by most of its clients. If you ever want some free comment karma on Reddit find any submission, complain about the file size of the site and watch the upvotes from conflicted developers fly.
However, these things have context.
If this website were for a typical business then yes, you'll have "bugs" flying in from everywhere from the client. They'll not be able to view it on IE7 because that's the only browser their IT department will allow, their users will also be running this site on an ancient computer that cannot handle a dozen jQuery plugins running on a single page and they'll start making demands that you, the developer, will find unreasonable because "that's not how HTML5 works!".
However, if you're creating a new business with a set market of people with newish machines running modern browsers then you can afford to use "new" technology and to sacrifice your precious page size for some creativity. For some markets it is a good thing if a site will heavily utilise JavaScript. For some web applications, it's almost necessary to rely on JS.
Regardless, a good developer will be able to get a modern site working well in legacy browsers even if the user is on IE6. I'm no senior-level developer, nor am I solely a front-end developer, but I can at least do that much on a large-scale client site without any trouble. If I can do it then I fail to see how so many developers can.
Yes, developers will not learn. The average developer is happy to throw as much jQuery at a problem as they can, and they're happy to go nuts because they own a decent computer, use the latest browsers and have a fast connection. The best front-end developers I've ever known understand these problems and can provide similar or better results in an optimised way.
Sergej P. Koroljow (1907-1966)
Flash websites or one page JavaScript clusterf*#ks come from developers, who want to achieve cheap cool looking effect in order to cover the lack of real value in their product. They also want to have limited amount of technologies in their stack: Backend -> Server app -> JSON -> Web app, because it gives them false feeling of coding their projects faster.
Web development is like playing football or any other sport for the masses, everyone can do that, but only few can achieve good results.
This makes the article sound like a bullshit linkbait from Captain Obvious.
After that, the bad behavoir this article describes that I happened to code is crap I didn't want to do but was forced to in order to satisfy a clients desires.
Most of the horrible decisions that occur in software development are not the fault of a developer - look to their managers or clients for blame. In my case at least I argue quite voraciously to adhere to standards. I almost never win.
If your site is essentially a collection of documents, then I expect it to work with standard browser navigational tools, be easily linkable and function without Javascript being enabled, it should also work in old browsers.
If you are doing an application on the other hand, It's far more reasonable to expect an upto date browser and JS etc. I almost don't want to know that it is running in my browser, because the navigational toolbar in my browser is probably a bad fit for whatever it is that your application does.
Of course there are blurry bits and grey areas here. But as a rule, the front end of your blog is a website and the "admin panel" is a web application.
Oh, except for JQuery, node.js, etc., etc.
Face it - we have SO MUCH MORE POWER now than we did just a few years ago, and so many more tools for managing and abstracting that complexity. In fact, there seems to be a trend of abstracting complexity while focusing on lightweight codebases. Sounds like progress to me.
For examples see Issuu, Slideshare, and especially Prezi.
I'd be lying if I didn't mention that I miss the days of HyperCard stacks and MacAddict CDs.
Oh, and for the most-distracted among us... there are always books.
But why does it have to be that way? Those are just some blog posts that I want to read. Plain simple text. There isn't anything interactive there. It's not a web app. Why do they need some obscure javascript that messes up everything and makes the website unusable?
I enjoyed parts of this article and was left with one overarching theme - web developers really need to learn proper testing techniques (and their employers/clients need to learn why QA is important).
How many ad agencies have taken to calling themselves interactive agencies? How many of these have dedicated QA teams with different devices and a good array of testing tools? How many of the developers who work for companies like this get time to test their sites? How many hear "if you were better at your job, you wouldn't need to test sites"?
I'd also suggest that business schools start teaching marketing students to build simple web apps. A pint says that many of these problems stem from young marketers who want to be edgey, despite having no clue where the edges lie. My University has an Online Marketing course, but they don't teach anything more advanced than building a spreadsheet with multiple worksheets in Excel. Maybe this just proves that marketing is too important to leave in the hands of marketers...
Progressive enhancement is the best design pattern for web development, and more developers need to design in this way.
If you've ever tried to middle click a bunch of links on, say, a big corporate news site and had your current tab change unexpectedly, now you know why.
Dear Twitter,
I love the service. You guys seem to be a great bunch. I use bootstrap a lot. But, if your most basic functionality is buggy, how do you expect people to use the service (and not abandon you)? I know, I know. You are having front-end issues. But you seem to be stuck in an endless re-factoring loop. Please fix it. And stop trying on languages as if they were hats. Pick one, and live with it.
But by the standard laid out in the article most smartphones suck, most desktop apps suck, etc.
But web sites, like smartphones and apps, aren't built by a single amorphous group of people called "developers". No, no, no, the development process is defined by executives, marketers, IT, designers and yes developers. Saying "Do Web Developers Ever Learn?" is misleading. It's like placing the blame on the engineering staff at Nokia for creating sub-par phones - when there's plenty of blame to place on Nokia's executive management.
A broken and stupid product is evidence of a broken and stupid company culture. Bad developers can be replaced. But a broken culture can force good developers to do bad things.
This is precisely where I finally understand that the article is merely an opinionated piece (i.e. it doesn't state facts) and a pretty misinformed one at that.
All these things are plain hacks to try to bend the document shown by the browser into an application of some sort.
You can praise the small, slow, and static sites, because of what they're good at, but let us also point out that they aren't optimized for desktop browsers to date, don't utilize the speed of their upper clientele of users to offload processing and handling to the front end, and also don't accomplish as much as possible without the need of a state change.
I like what you put regarding complexity, because let's be realistic, as web developers, are jobs are constantly shifting from technology to architecture to agile to scrum to etc.
The author is complaining about mistakes in hindsight, and tries to complain about modern web apps having the same problems? There's always a new frontier in web development; if you can't handle the fact that certain api's become deprecated or that certain features a dev used aren't completely implemented, then do it better yourself. Update older tutorials, evangelize the correct approaches to problems, then, you'll do you part to remove some misinformation of outdated solutions that others are using.
media queries vs two separate projects - responsive and flexible one site fits all approach vs less resources served for smaller mobile version and reduce complexity(?).
web fonts / assets management - this is a growth issue or a design issue focusing on either OECD/Fast Internet or Server Load. It is somewhat an issue, but not something to cry over really.
his complaint about his textarea box are ill founded. He's using posterous' system, and should build his own if he doesn't like it so much. Isn't it a free service?
modal / gui decisions - usually client/manager driven. Can't blame me on this one. I'm all about pages and lightboxes.
his complaint about mobile browsing is one that is justified, but one that isn't any modern developers fault. My first 10 sites were all responsive. Now some clients don't want it. How is this my fault? This does take extra time and consideration, unless a client wants a very simply mobile site only.
Also: biased technology evangelism and special interests influencing web standards and popular opinions. These tow are probably the root issues.
You also seem to have not taken into account how new HTML5 is. Sure generally a semantic solution exists now but when the vast majority of sites were written this wasn't the case.
To put it in a different way, current web standards encourage people to abandon page model entirely. When they need SEO, the thought is "oh, damn, I need to re-implement my wonderful JavaScript on the stupid server". That is backwards and is not progressive enhancement.
What we really need is an update to core standards (not JavaScript) that allows for building dynamic applications in declarative way and without abandoning the page model. Such updates are possible.
I'd like to see some additional examples of this arbitrary limitation in the GUI. It seems to me that many design choices can be classified as limitations. If the user doesn't understand the reasons behind the design choices, then the user might mistake them as being arbitrary.
I CAN middle-click the following Google link types:
- Search Result
- Plus User Name/Icon
- Plus Link in Post
- Some links in Google Help.
I CANNOT middle-click the following:
- Map Search Result
- Plus "Fun & Interesting" results
- GMail Message
- Some links in Google Help.
Take, for example, Twitter--
You CAN right-click on links like:
- "Tweets"
- "Following"
- etc.
But you arbitrarily cannot right-click:
- A link to the user's "Recent images"
- The link to a user's profile from "Recent images"
- etc.
Would that really take it into account? Surely you'd be loading a new link without the state that the client has created, you'd need to push the state to the server and construct the links based on that - at which point it seems you're duplicating effort at the server and client.
Links/buttons that open on middle-click. I middle-clicked because I wanted to open in a new tab, this page should stay where it is.
Sites that don't work at a DPI that isn't 72.
Those are the most immediate things that annoy me.
It's way too wide for my taste and not very readable.
This phrase caught my eye. Have any concrete examples? I generally feel like continuous deployment is a good thing but am open to having my mind changed. Like anything else, it can be abused & misused but assuming there's a quality gate (tests, etc.) then why the generalization?
* Disabling copy and paste in web forms
I would just use ELinks all day if I could get away with it.
I don't think we'll ever get that back, though. It's all about engagement and interaction, these days.