Debugging is an essential skill for any programmer. Mastering this skill can help you identify problems quickly and effectively in your Python code. Without knowing how to debug code, developers will face endless hours of frustration trying to solve problems.
Fortunately, Python’s built-in tools and debugging techniques make it easy for developers to identify and fix errors without wasting too much time. To help you get the most out of your Python coding experience, this article contains a list of the top debugging techniques for Python developers. But first, you must know the importance of debugging and its practical use cases in the developer community.
The Importance of Debugging
As mentioned, debugging is among the essential Python skills that all developers need to know. A common misconception of debugging is that it’s only necessary for complex projects. In reality, debugging should be part of the development cycle of any project, regardless of its size or complexity.
This process helps you identify and fix bugs in your code quickly and efficiently. It can also help you better understand the program’s flow of execution, which enables you to make more informed decisions about improvements or modifications to the code.
Debugging Use Cases
A common mistake of new developers is to assume that debugging is only done to correct errors in code. In reality, debugging is used for more than just fixing errors. Here are some of the most common use cases:
Handling Python code errors that occur during program execution.Errors can be caused by incorrect syntax, type errors, name errors, etc. Different types of errors can occur in each code, and good debugging skills can get you out of a jam.
Investigating problems with code logic or implementation.This could include issues such as unintended infinite loops or unexpected output from functions. Debugging can help programmers determine the root cause of these issues and identify solutions.
Testing code for desired behavior. Debugging can be used to test if the code is working as intended. This could include checking for outcomes from functions, or ensuring that calculations are performed correctly.
Locating and removing code that is no longer necessary.As a developer, you should know that code can become obsolete over time. Debugging allows you to identify and remove obsolete or redundant code from your project. This could include dead code, duplicate functions, or redundant variables.
Identifying potential performance issues in your program. Poorly written code can significantly slow the running time of a program. Thus, accurately tracking and diagnosing these problems is essential for efficiency. And yes, debugging can help with that.
Common Debugging Techniques For Python Developers
Now that you understand the importance of debugging and its various use cases, here are some of the most helpful techniques for Python developers:
The “print()” Function
The simplest way to debug a program is by using the print() function. This can be used to debug programs by displaying values in real time. But how, you may ask? This function allows you to print out variables and values to gain insight into what is going on with your program. It also helps you identify errors that appear during the execution of your code. Through this function, you can easily track the program’s flow of execution and identify any potential problems along the way.
Integrated Development Environment (IDE)
An IDE provides a suite of tools to help debug code more effectively. With features such as syntax highlighting, auto-completion, debugging consoles, and breakpoints, it allows you to quickly identify and fix errors without having to search through your code manually.
An IDE is present in almost every programming language, and Python is no exception. Popular IDEs include PyCharm and Visual Studio Code as the go-to choices for many developers. If you have the resources, you can try out different IDEs and find the one that works best for you.
Debugger
A debugger is a powerful tool used to step through code line by line. It can be used to inspect variables, set breakpoints, and trace functions as they execute in real-time. This helps you identify the exact source of an issue quickly and easily.
The Python debugger, known as pdb, comes installed with Python. It allows you to inspect the flow of control in your code. You can also set breakpoints with pdb which allows you to pause at specific points during program execution so that you can investigate what is going on at that time.
Logging
Logging can be used to keep track of errors and detect any unexpected behavior during the program’s runtime. This provides you with a record of events that can be used for further investigation into the cause of an issue. Many seasoned developers use logging as a reliable way to track errors and identify improvement points.
The logging module in Python allows you to create basic loggers that can be used for debugging purposes. This module also includes more advanced features such as custom levels, filtering, and formatting, making it even more powerful!
Conclusion
Debugging is one of the most critical aspects of development that every professional developer should learn. You can quickly identify and solve problems in Python code by learning and mastering the debugging techniques listed above. Remember, debugging is an essential part of the development process, so learning how to use these techniques efficiently will help you become a more productive and successful developer!
We love sharing stories of small teams or even groups of friends getting together and developing innovative products. What’s more interesting is the journey they take as well as the difficulties they face and the learnings they acquire. Today we shed light on the story of a small product team who left their jobs to work on an idea that at first seemed simple but turned out to be quite an adventure! Here is the story of Adopto Bug Fixing – an automated bug reporting tool that helps tech teams receive fast and detailed bug reports.
Our adventure as a startup starts with a product team composed of a product manager, a tech lead, a full-stack developer, a UI designer, a QA tester, and a user researcher. We’ve always shared the desire to build something new to be proud of, so one day we decided to leave the previous company for which we were all working and follow the dream of building our own product-based startup.
“Fall in love with the problem” is the most popular recommendation shared among product people, and those founding a new startup. But here we’re talking about a startup whose 80% is made of builders, people who love to do one specific thing: build solutions. As Dan Olsen once said, “We live in the solution space”, and this is probably the truth when talking about a tech team. So we initially tried to use a shortcut: validating a solution without having validated the problem, as many did before us. We began this adventure with a solution in mind, a leftover from our previous experience, and we tried to look for a fitting problem, and for a market segment that could be interesting. A bit like when you are a child playing with geometric wooden shapes and you try to fit a circle where you should put a square. A true nightmare.
Like many of you surely know, what you should be doing before developing a product, and even more during the very first months of a product-based startup, is NOT building and developing solutions. Your time and energy should be focused on a series of problem discovery activities, ranging from customer interviews, and market research, to competitor analyses. Luckily for us, after banging our heads against a few brick walls, we realized that the solution we were developing wasn’t going far because there was no problem-solution fit, so we hit the brakes and pivoted away.
We braced ourselves with patience and started our quest for a problem that was worth solving and could make us passionate about. “Since we are a product team”, we said, “let’s start exploring some product-team-specific processes”. We deep-dived into processes related to developing new features and those related to the resolution of bugs and technical incidents. Of course, fixing bugs appealed to us much more than developing new sexy features!
We’ve spent the last four months doing customer discovery, interviewing potential customers, talking to them on LinkedIn and Reddit, on Discord channels, and in many product communities active on Slack (p.s. If you ever need feedback on any product you’re working on, I’d suggest getting in Mind The Product, The Product Folks, and The Product Coalition. Everybody is super generous with their feedback and ready to help out). As you can imagine, we had to work against the natural tendency to find shelter in the solution space, especially when at first we couldn’t get many people to talk to. But we managed, mostly because we were scared otherwise we would have to pivot again, and that’s a very painful process, as some of you can surely confirm. So after having chatted with hundreds of people among product managers, customer support reps, and account managers working for companies of various sizes, colors, and shapes, we validated that indeed there is a real problem with bug reporting.
Apart from some specific peculiarities that define every company, the current process that is followed in many places can be simplified like this: bugs (or presumed ones) found by end-users are reported to customer care or customer support, who are then responsible for the thankless task of manually collecting some technical information that is often hard to get -just imagine you need to ask an average user to share the screen and use the browser inspector to be able to check console logs. Then the customer support agent gets to open an issue to report that information in a ticketing system, following a more or less structured process.
This process creates a clear bottleneck: the team responsible for the resolution of the bug receives a report that is usually not very detailed. Not only doesn’t that help identify the steps to reproduce the error, but incomplete reports often lack the technical specs needed to distinguish between a real bug and a device/user-specific error, or even a bad design. This is why, once the ticket is opened, bug reporters and developers initiate a conversation that goes back and forth several times to request the missing details. Sometimes, customer support agents are even forced to reach out again to the end-user to find out more about the bug. This bottleneck is strongly felt by both parties involved: it is an eternal ping-pong that leads to a waste of time, without having any assurance that the bug will eventually be identified and fixed. Here we’ve collected some of the most interesting learnings we gathered on the way. We’d love to share them with you:
1. There is no need for a process…until you actually need one!
The very first thing we learned during our customer interviews is that there is a specific moment when you realize that your team won’t survive if you don’t put in place a somehow structured bug reporting process. We noticed that teams usually move from receiving direct calls or Slack messages from colleagues finding bugs to having a dedicated space to collect all reports. You can have a basic version of this, like a shared spreadsheet, or an #issues Slack channel where the tech team manages to gather all complaints shared by colleagues. Those in need and the bravest, too, even go a step further and build a template to guide colleagues in what details they need to reproduce and triage the bug, so they can quickly define its priority in the backlog.
What are the details that if present speed up the whole bug reporting process?
Where is the bug? – That is, all information that allows the team to exclude problems that are not widespread, but related to certain devices, OSs, browsers, app versions, or even user IDs.
Steps to reproduce – The actions that led the user to find the issue. The golden rule is “the more detailed, the better”. Usually, this information can be obtained only by directly asking the end-user to describe the process they follow that brought them to the bug.
Expected behavior – Bugs are very often unfortunate design choices that produce some friction when using the product. To be able to spot these non-bugs, it’s important to ask the user to clarify what behavior they were otherwise expecting to see.
Technical details – In an ideal world, frontloading helps make the bug resolution process overall more efficient. This is why it is a good practice to immediately collect all those technical details which could later help testers and developers identify the issue, such as network requests, and console logs. When reproducing the bug is not straightforward, details like these come really in handy. Yet, collecting them is a real pain for non-technical colleagues who have to directly ask customers and users. Imagine asking a user to share their screen and activate the Browser inspector so that you can collect the logs. A bit of an extreme situation, especially when dealing with users with low digital literacy.
Priority – The goal is to provide the tech team with an estimation of how quickly they should act on the bug and plan accordingly for the next sprint. This metric can be determined by different factors, such as the number of users that could experience the bug, or the importance of the feature that results affected, but also the impact of the reporting client on the company’s total revenue.
Unfortunately, the truth is that all the effort put into providing colleagues with a template that guides them to report a bug doesn’t always pay off. There will always be someone who won’t follow the suggestions, who prefers to spontaneously make a phone call or send a Slack message directly to the product manager or a developer. And from here we move to the second learning.
2. Templates are useful, but never enough
At least once in our professional life, we’ve all witnessed a colleague who refused to adjust and use a new tool that would have facilitated and sped up not only their work but everybody else’s. This is because the adoption curve for an internal tool of this kind follows the sinusoidal shape of any other technological innovation introduced in the last two centuries (but have a look here to read how the pace is gradually speeding up).
What’s important to bear in mind is that for any new tool or process, there will be one or two colleagues out of ten who will enthusiastically try it out – the so-called innovators and early adopters. Of the remaining eight, though, seven will need to be convinced, pushed, and engaged even just to give it a try, and one-two will likely never accept change. This is the truth, it hurts, but the sooner we accept it, the better.
Chatting with many product managers we identified another point that is very, very painful: even when you have some guidelines about how to estimate a bug priority, non-tech colleagues always report “High priority”.
“Consider, high priority is given even when they are talking about a typo or a misaligned button in the interface of an internal-use-only platform”, many confess with frustration.
This is truly one of those cases where you get nowhere: every team has its own KPIs and success metrics. If we ask a customer support rep, they will say their goal is closing support tickets as fast as possible. If we interrogate an account manager, it is high retention rates and an NPS equal to or higher than 9. And indeed, helping the unsatisfied user or client by making sure the problem is fastly and efficiently handled seems a very high priority for these roles, which are usually the most active in reporting bugs and technical issues in the first place.
The only thing we can do is take this factor into consideration, and use some empathy – yep, exactly the same empathy we try to use with our users! These colleagues have different goals and jobs to be done, so get ready with a bug triage process that is independent of the level of priority that they will mark. From here we move to the next learning: the (oftentimes unsatisfying) conversations between the tech team and non-tech colleagues.
4. “Yep, sure! I’ll let you know” doesn’t work
We’ve just mentioned that the product/tech team’s KPIs are quite different compared to those of colleagues working in sales and customer support. Let’s play a role game and get in our colleagues’ shoes -we have to apply that empathy we mentioned above: I’m a customer support agent and a client contacts me to report a technical issue, I bring this information to the tech team after collecting as many details as I can (although I’m sure the developer won’t be satisfied, as usual). It should go without saying that my need is to be able to check the status of my report so that I can show the client that I’ve not forgotten about them, I’ve paid attention and made sure their problems will be solved asap. Even when they contact me again the following days. It’s easy now to empathize with this colleague, isn’t it?
Then you should be surprised to hear that many of the customer care reps or account managers we talked to are not satisfied. The “Yep, sure! I’ll let you know” they receive from their tech colleagues doesn’t satisfy their simple needs. Most importantly, it doesn’t give them the chance to do their job at their best. Of course, we cannot expect the same colleague to then go the extra mile to gather all the details to make our job easier and less frustrating, am I not right?
Companies that believe in a powerful alignment between product and sales/customer care invest a bit and provide non-tech colleagues access to the product’s task management platform (e.g., Jira, Trello, or ClickUp just to name the most mentioned). In this way, as a task progresses, the colleague receives a notification and can address the angry client who’ll get in touch again the following day.
5. QA testing is not sufficient
The very last learning we want to share is about testing, and here we really collected mixed feelings. On paper, all product teams acknowledge how important it is to have a testing procedure in the pipeline before releasing changes to production. This procedure should guarantee that code is error-free, what’s known as Quality Assurance (QA) testing, but also that the user experience and the app usability are optimized, known as User Acceptance Testing (UAT). Everybody agrees this should happen.
Yet, about half of the people we interviewed confessed they don’t have dedicated resources for testing activities. In some cases it’s the product manager that carries out the task, testing the product and trying to imitate dummy user’s behaviors, such as clicking on the wrong buttons. In other cases, it’s the developers who test what they just built – and here we could (but won’t) start the huge debate on the validity of this practice (refer to this article to check popular arguments on the topic).
Nevertheless, there are several organizations where not only is QA testing done properly, but it is also automated to be very efficient and limit human errors. Nowadays many tools automatically notify you when they find code-specific errors, nothing new on this site. Yet, as many confirmed, the problem is that many bugs are not really bugs (strictly speaking, only code-specific errors are). Most of the time, the “bugs” are actually unfortunate UI/UX choices that the user perceives as technical issues. These cases represent the majority of the reports that tech teams receive, according to the product managers we interviewed, and there isn’t much we can do except bracing ourselves with patience and a desire to improve.
Adopto Bug Fix
You are probably wondering how our startup’s story ends now that we’ve finally learned to carry out a proper customer and problem discovery. After all the interviews, the individuation of the problem, of the job-to-be-done with the various pain points associated with it, we finally moved to the solution space. And here we started defining and building Adopto Bug Fix: an automated bug reporting tool that helps tech teams receive fast and detailed bug reports, without wasting time and precious resources in back-and-forth conversations with customer care and end-users.
Picture this: a user gets in touch with customer support to report a technical issue, the rep simply asks the user to press a keyboard shortcut, or click on a button on the app, and to reproduce the same steps that led to the error in the first place (this last one is a standard procedure that customer support usually carries out when receiving a report). That’s all!
Adopto Bug Fix works with a snippet of code that is pasted into the target platform’s code. It behaves like Siri: it’s quiet and invisible to the users’ eyes unless it’s activated. After the activation (with a keyboard shortcut or a click on a button), Adopto starts recording the session and collects a series of information. Among the information that it collects: there is a screen recording to check the user’s behavior on the app, the user clicks and text input, console logs, and network requests. But also specs about device and OS, screen resolution, and user ID. All these structured details are then conveyed in a report that the team can access from our platform. The report can be easily shared in any task management system. In this way, you can exploit the existing communication process you already follow to share updates with non-tech colleagues (we mentioned this at point 4).
As for today, we are in the Beta phase, meaning that we are improving the user experience and developing new functionalities thanks to the help of some product teams that have started using Adopto in their bug reporting workflows. These teams are young (not talking about age, but about product maturity), have a WepApp currently under development, receive many incomplete bug reports from end-users and colleagues, and have tried to solve the problem with a solution that didn’t bring the expected results. If you see yourselves in this description and believe Adopto could make your team’s life easier, check out our webpage and sign up to become a member of our Beta program!
From a common developer frustration to an award-winning company that has clients like SAP, IBM and Mentor, what does it take to turn a problem into a lucrative business? I had a chat with Greg Law who is the co-founder and CEO of undo. Greg went from founding his company in a shed to building a business with top enterprise customers. What we all want to know is – how? Read on and get inspired! Could you be the next Greg Law / Undo?
Vanessa:Tell us a bit about Undo.
Greg: Undo is a tool that allows developers to see what their software did and why, at any point in time. The tool (LiveRecorder) allows engineers to record the execution of a program and wind it back to see exactly what it did to identify software defects. You can step line by line in a debugger – forwards or backwards – and see all of the program state too.
Customers use us when they are completely stuck with an issue, and rather than guess what the problem is, they can pinpoint it. There were devs who would spend days, even months trying to figure out the source of a bug, and they try LiveRecorder and it enables them to figure it out in a few minutes.
The tool was originally aimed at the enterprise market, but more recently it has been used by more smaller companies, even those with small teams.
“The pandemic helped change this, there was no more travelling to meet with potential enterprise customers, and thankfully the tool was matured enough that it could be downloaded by people from our website, without the need to support hundreds of support requests.”
It was always part of the grand plan but the pandemic brought it forward.
Vanessa: How did you build your team?
Greg: It’s kind of the classic story. I founded Undo with a good friend of mine, Julian from when we worked at Acorn back in the day. We worked evenings and weekends together, it reminds me of a quote I heard recently, a programmers mantra of “We do these things, not that they are easy, but because we thought they were going to be easy”. We did eventually get to a v1, then bumped into an old friend that Julian and I had worked with at Acorn, he was looking for his next job. He joined us in the shed at the end of my garden, that was in 2013, and he hasbeen with us ever since.
Vanessa: How many are devs on the team?
We have 34 on the team.
Vanessa: Which collaboration tools do your team use to stay on top of the projects?
Greg: Git with GitHub on top of that, in fact in the early days it was just Git.
We used a todo.txt file and when we had 3 or 4 people that worked really well. It’s quite nice that you mark things in different states in different branches and it all just works. But obviously, it doesn’t scale. We used Phabricator for a while but ended up switching to GitHub.
Google Meet – and all of Google’s G-suite. There were worries about locking into a giant corporation but the convenience of it is too great!
Collaboration is about culture more than tools. We were definitely an “in the office culture” prior to the pandemic, and felt that the facetime, building deep relations and trust were good face to face, and that worked really well. That said, we were already beginning to recruit remotely in some exceptional cases. And of course, that has now changed 18 months ago and we transitioned like everyone else due to the pandemic.
If the pandemic happened ten, even five years earlier, it would have been alot worse for those in the knowledge industry. Even five years ago video conferencing was expensive so having Google Meet made things a lot easier. The most important thing with remote working is to write stuff down so that you can communicate asynchronously, not just remotely. Google Docs has been very good for that.
Vanessa: What kind of culture do you offer to developers in your company?
Greg: It’s one of those things that is quite hard to define. I cringe so often when I hear people’s answers to this question. It can be cheesy, and buzzwords. Often if a company publishes it’s values, they are actually aspirational values, kind of what they want to be better at, not what they are doing right now. So one of our values is no bullshit. Be honest with each other and ourselves.
That is a key component in building trust, and that’s the biggest one for me. There are the easy kinds of trust, like, do I trust that I can leave my wallet on the desk and it will be there when I get back? Then there are more difficult levels of trust such as:
1) Do I trust your intentions? Do I trust that we are trying to achieve the same thing?
2) Do I trust your judgment?
3) Hardest of all – healthy conflict.
I can say to you: “I feel let down, you didn’t do what you said you were going to do or you didn’t do a good job with that.” I can trust you enough that I can say that, and it’s going to be ok between us. It’s much easier said than done, and though we are fairly multi-cultural sometimes we can be a little bit too English about everything! So we need to be un-English about it, and say what we feel, obviously in a respectable, polite way, to have that trust and transparency.
And that was actually part of why we were quite big in the early days of building the company, not remote first, but having us all together. Not that you can’t build high integrity and high trust remotely, you can, but it is harder.
We were already becoming a remote culture and had a remote office in San Francisco, and we hired people from across the country, like in London. The first few people you hire will define your culture. As a founder, you have a lot less influence than you thought, culture is a self-defining thing. With picking the right early hires, we just got really lucky, we had no idea what we were doing. Now we’re in this new world and we hire much more freely regardless of location, and we have the core culture that we can build it on, it actually works really well.
Getting to know you
Vanessa: Have you always wanted to be a developer?
Greg: I wanted to be a train driver! Once I got over that, I got a home computer at the age of ten, my mum sacrificed to get the computer. At first I was just playing games on it (Commodore Plus 4) and she strongly encouraged me to learn and program with it, so I picked up a book to learn, out of guilt really, and from then on I was hooked, all I wanted to do was program.
Vanessa: Did you go to college and beyond or are you self-taught?
Greg: I took Computer Science at degree and also at A level not many six forms offered that at the time. I realised that it paid well to do something I’m good at. The world developer population is not growing that fast, which is surprising, We need to train more programmers, but we’re always going to have a big undersupply so we need to make that finite pool of programmers as productive as possible.
We need a healthy ecosystem to help people be more productive. Ten years ago, software tools were a brave business to be in. Now it’s one of the hottest places for VC’s to invest in.
Vanessa: Have you ever been involved in mentorship, either as a mentor or a mentoree?
Greg: We’re all still learning every day, I have mentored. In fact many of our employees are a mentor to me. We’re lucky that there is a healthy ecosystem in Cambridge. It’s amazing really – you can email almost anyone you can think of, even when you’re right at the beginning and they’ll spend a bunch of time with you.
The Future
Greg: Core tooling, slowly they have evolved compilers, IDE’s. Debuggers have not changed much over the years, new tools have come along but the fundamentals have not changed much over the decade
We see waves of tech. There are rapid periods of changes, computer operators were like train operators – if you used a computer for work that’s all you did, and no-one else would be let near them. Then in the 80’s people started using computers as part of their other job, now everyone is using them, and now there are smartphones. As these waves went by, the way we developed changed too – i.e. it goes in waves. Between say 1990 and 2010 the way we develop code was all evolution not revolution. Then suddenly it all changed again, first with agile, then CI/CD, huge amounts of reuse of open source, etc. With these big changes comes an explosion of tooling. It’s really hard to imagine what will continue. I think most of the tools we use today will still be in use in ten years, but they will have been added to. Like how GitHub compliments git, or our stuff does with Jenkins. I’m sceptical on the AI writing code thing – understanding of requirements through context and delivering creative solutions to that – it’s a million miles away from the state of the art. But I do totally see computers helping us to write code – the GitHub Copilot stuff promises to save a bunch of time. But it’s not quite as exciting as it looks because if you think about it, Copilot saves you time typing in the code sure, but what proportion of programming time is actually spent typing the code in? Pretty small. A much larger chunk of time is spent figuring out why that code you typed in this morning doesn’t do what you thought it was going to do! That’s why we started Undo, and I think we’re going to see a lot more around this notion of understanding or auditing exactly what happened.
Collaboration will be key. Asynchronous collaboration. Once you sever the link, you no longer require people to be geographically in the same place, well then you no longer need to be in the same time, either. This has potentially profound implications for how we might work. We have used version control in development for decades which allows people to collaborate remotely and asynchronously; I think these practices have a lot to teach a wider audience in asynchronous collaboration. In kind of the same way that the first word processing applications were actually code editors.
We’re good at writing code, but not at debugging, most devs spend alot of time debugging – remote and asynchronous collaboration through debugging would be great.
Vanessa: It was great to talk to you Greg!
We love to hear your development stories, get in touch to share yours.
HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools?
In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).
We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen.
Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps.
Experts point to a tools gap
As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode).
It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap.
Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”.
Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it?
HTML5 is like a car without a dashboard
[tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools.
With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created.
Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation.
Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference.
Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post.
Better tools are needed
HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools.
With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs.
Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps.
What other improvements do you think are needed in HTML5? Download our research and participate in the discussion.
