What do you need to make a successful web app?

>This is the biggest one. I have seen many, many projects held back by the idea that they need eight nines of reliability and a geodiverse HA cluster before they can even start, where a single server with a half-decent backup plan would be more than enough.

This seems weird to me because I'd gotten the impression, from reading around, that it was more often a problem that someone's servers weren't ready to handle the throughput due to not enough servers, not being written scalably from the start, etc. And I've seen this happen a ton of times with people's new web apps that they post to HN or reddit. It even has a name over there, the "reddit hug of death" when it's overloaded by the new demand.

I'd say add them in after you have enough to pay one person full-time.

Now, I'm quite the opposite - whenever I add new functionality, I write as much tests as possible - it makes life so much easier in the future. Yes, sometimes it can be irritating when you change one line in your code and you have to fix 10 tests, but the peace of mind when all tests run successfully after each change in code is priceless.

I never write tests until something is launched and it looks like anyone will be using it. There's no need to have test coverage for software that's going to be completely torn to shreds every couple of weeks until that first spark lights in the eyes of a user who finds the value proposition you've been searching for.

Unless you have the luxury of working with a full team and have plenty of time to kill (read: money to burn) you're going to want to cut as many corners as possible. If it is a fast moving new market it could save valuable weeks to skip out on a number of 'best practices'. You would be astonished at the number of products launched without a stitch of what would pass muster on a more mature code base.

The goal is to find something that people want, not to make robust software. That comes later. Pretending like there aren't up front costs to writing and maintaining tests is absurd.

You'll also find that if you're sticking to functional and stateless design patterns that your code is incredibly easy to reason about. Ditch the OO patterns like observers... Anything where new instances of objects are created, anything where you can't literally serialize the state of your running application, restart it, and get back the entire state you were just in...

People tell me that tests force people to reason about their code in such a manner. I think that reasoning about your code in such a manner is the really important part. You end up with code that you never need to step through or pry apart in a REPL. It just works (TM). I dunno, I've been writing application code for almost 20 years now. I've learned from a lot of architectural and implementation mistakes I've made over the years. State and side effects are the fucking enemy. All of the testing in the world isn't going to fix your ill conceived understanding of whatever new problem space you're dealing with.

I also find tests make the most sense when there are multiple developers working on a code base. A single dev isn't going to benefit as much from the cost.

And yes, again, tests do have a cost. It is absolutely ridiculous to argue that they don't.

And ditch the objects. They make no sense outside of a Smalltalk or Self environment.

After you launch and people are using it, after you've got a few developers working in the code base, after the product has actually stabilized to a set of more or less concrete specifications, THEN write your tests.

If it really is the frontier then cowboy coding is just fine. :)

The west wasn't won with prudence, it was won by taking risks and moving quickly. You're not the only guy with dreams of building that railroad. Someone else is already driving stakes in to the ground. You can go back and build a better bridge, a more efficient path through that valley, or a safer incline AFTER the line links up. The intercontinental railroad was a mess for decades after it was built but that didn't matter because the utility provided was immeasurable.

If you're just building another commuter rail in a busy town, well then I can't relate at all. Use your TDD mumbo jumbo. I'm a start up guy, I'm a cowboy, ON A STEEL HORSE I RIDE. AND I'M WANTED, DEAD OR ALIVE.

BTW, I have plenty of start up friends who successfully start new projects with tests. I mainly wrote this because I wanted to quote Jon Bob Jovi at the end there. :P

So if you are going to use a reset.css file, you should do some research. Check on google what other people are writing about reset.css files, read comparisons of different reset.css files, test different reset.css files on different browsers, etc. But then you've wasted an afternoon NOT BUILDING YOUR PRODUCT.

If you just accept that your website is going to look slightly different in different browsers, you will realise that you don't need a reset.css file, and you will save a lot of time.

The CSS reset is a convenient tool for the visual layout only. It helps with browser consistency and prevents margin/padding/font-size issues mostly, but it won't turn your idea into a successful product. I think that's the only message the article meant to convey.

That’s a bit of a stretch.

The current version of HTML5 Boilerplate includes several things in the header that probably aren’t exactly what you want, particularly if you’re supporting mobile devices.

It loads 4 distinct JS files. One of those is Modernizr, which is loaded at the top of the page and will therefore block, and there’s a custom class on the HTML element to go with it.

It loads 2 distinct CSS files.

It inherently has potential security and privacy issues that come from using any third party servers, in this case Google Analytics and attempting to load jQuery from their CDN.

Likewise, it has dependencies on some third party scripts, both Modernizr and the ones for Google.

And it contains an unprofessional nag message for users of IE8.

This is not a criticism of HTML5 Boilerplate. All of the defaults mentioned above might be a good fit for some projects, even many projects. However, none of them will be suitable for all projects, so the moment you start from HTML5 Boilerplate you almost certainly have some technical debt to pay off, just like any other template or framework or scaffolding system.

I guess some people just like to write their frontend code from scratch...? It's funny because the author wrote Zepto, of all people he should know about abstracting away cross-browser concerns.

I suggest an obvious but effective policy: when you need professional advice, speak to a professional.

The first time you need a certain kind of legal document — terms, privacy policy, employment contract, whatever it might be — speak with a lawyer.

When you set up your company, find a decent accountant who can get the proper structure in place. They can tell you the basics about what records you need to keep and when you’ll need to do things.

After you’ve done something the first once or twice, you usually have a reasonable understanding of what the essentials are, and you can probably do more of the work yourself to save time/money. The professionals can then become more advisors and reviewers than the people doing routine paperwork.

I also strongly agree with 'jakobe about finding professionals who are used to working with small companies, preferably by personal recommendation. It’s much more than just pricing: the whole way they work is often very different to how bigger accountancy and legal firms who are used to working with bigger companies work.

As a final tip, in most places there are organisations that support small businesses that you/your company can join. These usually have a modest cost, but IME membership can easily pay for itself many times over. Some useful services they might offer that save you time and/or money include providing templates for common types of legal document (which you can use as a starting point if you’re drafting yourself), providing legal and/or tax helplines (which you can phone when you just need five minutes speaking with someone who knows what they’re talking about), and producing general guidance on things like contracts, tax, and insurance, with a focus on issues affecting small businesses. You might also find you can get more attractive pricing on things like business supplies and insurance through such organisations, as they have much more bargaining power collectively than any single small business has on its own.

* When you are just starting out, it makes a difference if you pay someone 300€ a year to do your taxes, or if you have to pay 1000€. Stay away from the big companies. They will charge you for every phone call. Ask other small business owners for references.

Please, let's refrain from blanket, subjective statements for once.

We have run into issues on layouts where the project leader wanted one thing, then changed his mind two or three times (and this was after being implemented) so that view is a little tough to work with now, but generally speaking if you have a clear picture of what's important to your user it's trivial to present one experience to mobile users and a very different experience to desktop users based off the same markup.

The key is is tilling your markup down to the minimum to suit both layouts. When you have too much markup it gets tougher to make it responsive.