I’ve been a huge fan of Laravel ever since we built an app for Crocs with it at Voltage. In 2014, some developers at Voltage wanted to join a Laravel meetup but found that there wasn’t one east of the Mississippi. So, they started one and I’ve been a part of it ever since. We talk about a ton of stuff at a high level.
So far, I’ve only used it to built a very simple app in Laravel, but want to get some more serious experience. I’d definitely take a lower-than-usual rate to get a project under my belt.
This project was basically complex theme hacking. I hate theme hacking because I have to deal with all the bugs/nuances of other people’s work without the benefit of being familiar with the whole codebase.
It was fun to get a little more experience with Shopify. A couple challenges were getting the color thumbnails on the quick view and product page to show product images instead of colors.
Since the last project I did on this platform, Shopify added the ability to organize theme options better. This ability came in handy because the client wanted to be able to edit almost all static content on all pages. Unfortunately, Shopify still doesn’t have the ability to allow the user to add custom data types in the admin, so I had to do it all in the theme options. Hopefully, custom data is coming soon, but for now, theme options are definitely working better.
Corvida Software hired me to add a feature (tracer) to their Hookify app. The feature is pretty cool, it allows someone to quickly ping any endpoint on the web and test the responses. You can save these “traces” for later so you can ping at anytime. It also saves past responses.
I quoted this project and they came back and said they’ll only pay half that much. They said I had made some mistakes in my assumptions. I don’t typically do projects on a fixed basis, but this was our first one together, so I figured I’d give it a try.
Needless to say, it didn’t end like I wanted, but I delivered them a finished project despite loosing money on the deal. That is just how I roll. They were great about it and increased their budget a little bit.
I had fun learning all kinds of stuff about pinging API’s with ajax. There are all kinds of nuances that you have to learn when creating a tool that can be used to ping multiple APIs. I also had fun using the Select2 library to add auto completing and validation to a text input.
I did a guest lecture Tuesday night at Ignition, a coding school run by Spark Boulder that prepares students for their first coding internship. It was fun and I learned a lot about how to improve lecturing abilities. I also got a lot of good questions and one question that I didn’t think I answered well enough, so I thought I’d elaborate.
If you have no interest in JavaScript, you may want to stop reading now. 🙂
The question:
Should we only select DOM elements by ID in JavaScript? If so, why are you using only classes?
This is a great question.
In most cases, it makes sense to separate JavaScript (JS) selectors from stylesheet selectors. This allow you to change presentation (styles) without breaking behavior (JS), but are IDs the best way to do this? I say no. Below I walk through several reasons why IDs may not be the best solution and I suggest an alternative.
Some Reasons I Don’t Use IDs As JavaScript Selectors
IDs Can Only Be Used One Time On A Page
Let’s say we have a group of repeating elements to which we want to bind a click. With a class it is easy, but with an ID you’d need to iterate the ID name (#element01, #element02, …,#elementN). This isn’t a big deal when using a loop to create the HTML. In the jQuery/JavaScript, however, instead of using a simple selector like $(‘.element’) for a class, you’d need to use a more complex one like $(‘#element01, #element02, …, #elementN’). And if you have a dynamic number of elements? Then you’d need an even more complex selector like $(“[id^=element]”). This selector grabs any element that starts with the ID element.
No big deal. Right? I guess.
The complexity isn’t that bad and you still get the benefit of separating behavior and presentation, but what if you need to target something inside the repeating element. A good example of this is an accordion; you know, a list of items (siblings) that expand on click and collapse when a sibling is clicked. With jQuery, you’d add a click event to an item where [id^=element]. The element that is clicked can be used to find it’s sibling, but if you’re only using IDs, you’d also have to add another cumbersome, iterating ID (e.g. id^=sibling) to the sibling (#sibling01, #sibling02) .
You can probably see where I’m going with this, given complex and dynamic functionality, you’ll find it increasingly difficult to iterate every element that you want to select with JavaScript.
Some people like complexity, but let’s say for some reason you can’t loop the HTML to easily make the IDs unique; for instance, when you’re not using real data. Prepare to waste time. And when the client asks to change the order of the elements? More time gone. And what about when your function stops working all together because you had two identical IDs? Not good. And what about when you accidentally bind #elementary and #elemental when you only thought you were binding #element+number. Yes, another debugging problem.
The fact that you can only use IDs once means that your code is more complex and difficult to maintain.
You Can Only Add One ID Per Element
Let’s say I add some complex animation to an element by ID. Later, I realize I want to add some unrelated analytics to that element as well. I could bind it to the same ID, but that could pose a problem if it also needs to be added to other elements on the same page. With IDs, there is no way I can add another selector to keep these unrelated behaviors separate.
I Like To Write Stuff To Be Repeatable
Let’s say I write a block of code using an ID and then I decide I want to repeat it later. If I used IDs I’d have to copy and paste the HTML, make the IDs unique, and go back to update the JS. Why not just write it to be repeatable the first time? You can’t do that with IDs.
Presentation And Behavior Are Often Interconnected
Good website design often includes changes to style based on the state of an element (open, closed, focused, clicked, etc.). An extremely easy way to do this is to use the jQuery functions .addClass(), .removeClass(), and .hasClass(). By its very nature, this feature requires that we manipulate classes with JS.
Many times, presentation and behavior are interrelated and separating them in some cases isn’t good.
I Like To Make Selectors Easily Searchable In JavaScript
I’ve worked on several big sites. These were built and maintained by many developers (in house and out) and they have a lot of moving parts. When adding and changing functionality, these sites have many files that affect the elements of any page—sometimes files on top of files.
Let’s say I need to make a change to a repeating element. It would be nice to search all files for the element’s selector (#element01) and then easily update; however, remember I had to use an iterating ID and a cumbersome JS selector; therefore, I can’t just search all files for “.element”; instead, I need to search for just “element”. On a big site, I’ll probably find hundreds of pages that contain that string, making it very difficult to find all references to this selector in the JavaScript.
I solve this problem in two ways, (1) I try to make my selector names specific and unique, and (2) I never modify the selector name in JavaScript; for example, if the id=”element01″ I always write the JS selector as #element01, never [id^=element]. This way I can easily search for it and find anything and everything that is bound to that selector. You can’t do that with IDs on repeating elements.
A Proposed Solution
So, what if we all agreed on a solution that gets many of the benefits of using IDs while still solving the problems I introduced above? Would it be adopted? Probably not, but here goes anyways.
I submit that instead of using IDs for JavaScript, we just use classes. Ok, hear me out. If behavior and presentation are interconnected, we attach both CSS and JS to the same selector, but we never alter a selector’s class name in JS to make them easily searchable and update-able. Whenever we make a change to presentation, we just search the whole site for that string and update any JS attached to it.
Whenever possible, we separate behavior and presentation by using a naming convention to identify classes that are only used as JS selectors. For instance, we add .js to the beginning of selectors only used for behavior (e.g. .jsElement, .jsSibling, etc.).
This simple rule would solve all our problems. What do you think?
Rebuttal
I’m sure there are things I didn’t take into account above. I’d love to hear your comments below. In an attempt to rebuttal some of the easy responses to my proposal above, I’ve included a couple thoughts here.
I know someone is thinking, “but classes are slower selectors than IDs.” Yes, but I’d argue it is negligible. You’re still talking milliseconds. I heard someone say once that when you write code, write it as elegant as possible even if it occasionally sacrifices speed. Then, go back and rewrite if only if necessary (although it isn’t most of the time).
And others are thinking, “but data elements as JS selectors would be better.” The problem with data elements is that you’ll always have instances when behavior and presentation are interconnected. Why not just have one simple rule that solves all our problems, rather than using data elements except when we don’t. And data elements are slower. 🙂
I have an interesting power as a web developer, with mere words, I can give people a horrifying condition called sticker shock. If you’ve never felt it, imagine a mix of the feeling that someone is trying to steal your money and the feeling of disappointment when a solution to all your problems exists but you can’t get it.
Truth is, most people have no idea what a website really costs. They’ve heard stories of the wonders and affordability of hiring developers in distant lands OR they’ve seen the tech giants give away amazing technology for free and they think this stuff must come easy. I know because I was once a like them.
A question I often get is, “how much would it cost to build a site like [insert the name of a famous tech company]?”
When asked this, I realize that people usually aren’t thinking about the fact that these tech unicorns are created using hundreds or thousands of very pricey software engineers over long periods of time for millions of dollars.
I’ll admit that even the least tech savvy among us intuitively understand that technology is scalable, you code it once and then benefit an infinite number of times at very little additional cost. That said, the “coding it once,” usually comes at a high cost. Why?
Technology isn’t cheap because the value it provides is enormous. This will always be true.
So, pretty much every time I get the question above, I hesitatingly use my shocking power. Unfortunately, it sometimes ends the conversation, but that is what it takes to have happy clients in the long run.
They usually have someone else build the site for cheap and then come back to me in 6 months to fix it. Sometimes I can, sometimes I can’t. One thing is sure at that point, the client is in crisis mode, they’ve lost lots of business, they’ve wasted money on development, and it is a much less pleasant experience for the both of us.
Cost of a Website
In an attempt to reduce the sticker shock of my future clients, I’ve included some numbers below. The following estimates aren’t meant to include outlier developers; you know, the shops/freelancers that price themselves far above/below the general market for one reason or another. Typically, outlier developers have a very unique niche OR they are about to go out of business.
Here is a table of site developers (Dev Shop, Freelancer, etc.) and the types of sites I typically see (marketing, eCommerce, mobile, etc.). Keep in mind, prices vary widely depending on (1) the number of templates, (2) the types and complexity of custom functionality, and (3) the technology you choose, but these should give you a good idea.
Projects
Dev Shop
Freelancer
Overseas
Beginner
Simple templated marketing or eCommerce site with little customization:
N/A
$1.5k
$1.2k
$1k
Custom marketing site with multiple pages and some custom business logic:
*cms stands for content management system like WordPress, Shopify, etc.
The numbers above are attempting to approximate an average, but they should probably be ranges because, as I mentioned, websites vary greatly in price. For example, we’ve build custom marketing sites for anywhere from $3k to $40k. Sure, $15k is in the range, but your particular site could land far outside the average. Some other reasons the price may vary include: the number of unique pages or components, the complexity of the business logic, the complexity of the data needed, and any third-party integrations needed.
If you’re looking to get a more accurate estimate, feel free to reach out, we have a quick way of estimating projects that turns out to be quite accurate.
One other note about the table above. From an hourly perspective, you’d pay higher in the range if the developer specializes in the technology you’re working with and less if they’re willing to learn it. You’ll also pay a higher rate for more experienced developers because an efficient developer at a high rate can often outperform a slow developer at a low rate. Let me repeat this in a different way, you can’t compare developers based on rate, you have to compare output to rate.
So, who should you choose? I can’t answer that for you, but I can share some thoughts that may help you decide.
Dev Shop (or Agencies)
Although I’m not an expert on agencies, I did work for an agency for 2 years and while there I also worked for several other agencies. They are definitely the most expensive solution, but that doesn’t mean they aren’t right for your project.
Some of the increased price is due to overhead and some is a premium you pay for strategy, experience, and speed.
Shops often do great work. The code you get is usually well written and eloquent and you can bet they won’t start on your project and then just disappear a month later. They also offer a cohesive team, all focusing on your project, which can reduce some of the risk of launching a new technology.
The only real downside to working with a shop, besides price, is they’re less invested in your project. The developers see hundreds of sites like yours a year and the minute your project is done they move onto the next.
A lot of people ask me if Buink falls into this category. We do call ourselves a dev shop, but our business model makes us more like a group of freelancers.
Freelancers/Independent Consultant
An established freelancer with a good portfolio and a work history will offer many of the same benefits that a shop will. The difference in price is because they typically have very little overhead and are not necessarily profit driven.
A good example of having less overhead is the fact that freelancers typically don’t have project managers as middle man. They talk directly with the client which saves time and reduces communication gaps. In other words, the client doesn’t have to pay for the project manager to learn what they need, then pay the project manager to communicate that to the developer.
Freelancers are also more invested in your project. You’re not just one of the many clients, you’re one of the few. Through time, they become invested in your business and have more personal incentive to do good work.
Hiring a freelancer may not be all kittens and memes, however, there can be some downside. Freelancers typically have less bandwidth than a shop and it may take longer get to market.
Also, freelancers generally have less credibility than a shop. Sometimes they’ll take on work they can’t complete and they may just disappear on you if they don’t like the project. Make sure to get good contact information for them just in case you run into a problem down the road.
As I mentioned above, we consider ourselves at Buink more like a freelancer than a dev shop, really we’re a hybrid that overcomes some of the issues of both.
Hiring an overseas developer is one of the cheaper options. The price is an obvious plus and if you can find the right developer, you may have no problems at all. Unfortunately, this isn’t my story or the story you often hear.
In 2011, I outsourced the initial development of one of my startups. At the time, I didn’t think I had the experience to build it myself and I didn’t have the time.
I contacted some local dev shops that all quoted the project at ~$25k.
I experienced a little sticker shock myself.
My budget was significantly less than that, so I found a company that worked with developers overseas and they quoted me $5k. The site took forever and ended up costing $10k. Looking back, I’m not surprised. Tech often takes longer and costs more than the original estimate whether you use overseas developers or those near home.
When I finally got access to the code base, I had more shock than just sticker. The site didn’t meet my specifications, it had ton’s of security flaws, and it had misspellings in functions and variables names that were very difficult to correct. In addition, it was very difficult to communicate with them. In short, I got what I paid for. If I had more capital and time, I would have re-written it from scratch, but I just had to go forward with it.
This is a huge reason to decide early how much you want to invest in your website. If you decide to go with cheaper options thinking that your website isn’t a big part of your strategy, you may have to totally re-write your site if that changes.
Everyone starts somewhere. If you find a diamond in the rough, you may want to invest in the person long term. They’ll start out slow and their code won’t be great, but it will probably work as long as you don’t start growing gangbusters.
Do-It-Yourself-ers
You may have noticed that I didn’t include the cheapest way to build a website in my table above, building it yourself. Technology to help you do this will typically cost you under $200 and a lot of your own time.
I was once in this group myself. I built my first website with a builder (Web.com), my second website on an open-source platform (Magento), and I currently own an eCommerce necktie site on Shopify. Today, there are some pretty credible platforms that help you build a decent site with no knowledge of code: Shopify, Bigcommerce, WordPress.com, ect.
These sites are great for getting started, but if you want to keep growing, your customers are going to expect a more professional, custom looking web presence.
In Conclusion
The price of a website is usually shocking. There are different options, but they all come with trade-offs.
I had a conversation last night with a good friend and very successful business man (I think he’ll be a billionaire some day, seriously). He told me how he worked for years with a freelancer at $70 an hour. He was happy with the work but then brought in a more experienced freelancer at $120 an hour. He found that the more experienced freelancer could do the same work 3 times faster and deliver better code. Turns out the more expensive developer ended up being cheaper.
Hope you enjoyed the read! May the price of your next website be a little less shocking.
I took a couple hours today and last week to get some Node.js practice. I built a basic app that can take an image upload and display it. The app was surprisingly simple to write.
I used two packages: node-formidable for parsing form data and fs for handling the image.
I can’t talk publicly much about this project out of respect for Voltage, but I wanted to include it in my projects because it was a great opportunity for me to continue honing my skills of UX/UI Design as well as back-end architecture.
Steven and I worked together to lay out early wireframes of the front-end and the back-end database architecture we’d use to drive the front-end. Unfortunately I never got the chance to finish the system because for unrelated reasons I decided to leave Voltage and start doing freelance web development.
I think I’ve said this before, but I love when I get a project that I code from the ground up. I like it for several reasons, the most significant of which is that I take pride in the cleanliness of my code. I try to do everything with the least amount of lines possible. A good example of that is the product menu on this site. The same code populates the top menu boat drop down as does the row of boats on the homepage and throughout the site in different places. If a link needs to be updated in the future, it only needs to be updated once, which should save time and make the code easier to maintain.
Other project highlights include the popup “Find a Dealer” map at the bottom of all pages. This map was made using my map code, which was refined significantly for this project. Hewescraft can add as many locations to the map by simply adding a location in the WordPress Admin. Although the design didn’t call for it, the code can also add a clickable legend that allows users to zoom to locations with a simple click.
Note: the site isn’t live currently, but should be soon. Since I left Voltage, someone else will be launching it.
