I'm a web developer of a small, local SaaS web application. It currently has about a half-dozen clients.

As I continue to design the application, it's become increasingly harder for me to convince myself to commit any time to the project, which has happened in the beginning phase. Having grown attached to the project and the code I've already written, I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.

As a university student applying for internships, I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work. I simply don't know any web frameworks, and don't know which one to start using.

I've landed an internship as a full-stack developer in January, where I'll begin to learn front-end frameworks, but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over, which is something I've done before. The app currently is built in PHP and jQuery (for AJAX calls) and uses MySQL for its database. Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? Thanks in advance.

  • 91
    Using a framework is meant to be cheaper, not objectively better. Business will always ask "why not cheaper" because that's their job. It takes many years of experience to answer "why this framework not that one, or custom". You cannot possibly give any meaningful answer to that question as a student/intern simply because you haven't taken part in enough projects to witness how a given framework works for a given problem. Without such experience, the only thing you can do is to fall prey for a given framework marketing. – Agent_L Nov 6 at 11:49
  • 24
    The only thing you know about the future is that you don't know anything about it. So just get on with living in the present. The future will find ways to kick you in the *** however much time you waste trying to avoid it! – alephzero Nov 6 at 13:08
  • 19
    "Having grown attached to the ... code I've already written" It's our nature to become attached to our work and resistant to changing it. But even if you do, it lives on in version control. Software is meant to be changed, just as the real world does. Don't be afraid to delete code or change it substantially when building upon it. – bitsoflogic Nov 6 at 15:14
  • 8
    As for scrapping the project, I'd advise against it. It typically feels great to start from scratch, because you get lots of momentum facing lots of problems you've already solved. Eventually though, you're back to a new problem that doesn't fit the model.The time rewriting could be spent solving the new problems instead. You can always address bottlenecks once you know what they are. – bitsoflogic Nov 6 at 15:17
  • 5
    @james_pic You do web projects without a basic framework (say asp.net core in .NET and so on)? So you reimplement the routing logic and all the other stuff on top of a simple http library? That seems excessive and I fail to see what advantage that should give you. – Voo Nov 6 at 17:20

Perfect is the enemy of good.

Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount of time writing an app which would scale to a million users, but it wouldn't be any better for your current six customers than what you've got today.

  • 22
    Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done. – Neil Nov 6 at 10:20
  • 83
    YAGNI, baby, YAGNI – Kevin Nov 6 at 13:23
  • 32
    Another case of "Premature optimization is the root of all evil". Maybe worth mentioning that you won't jump from 6 users to a million. If 6 clients are enough to pay for one developer, then even by the time you reach 100 clients, the code might need a different structure just to allow multiple devs to work on it at the same time. That's quite different from optimising performance and happens so much earlier than having to juggle a million users. – R. Schmitz Nov 6 at 14:32
  • 21
    @R.Schmitz That quote gets used these days in a completely different context to the way Knuth used it in Computer Programming as an Art. Knuth is decidedly against the whole "just start programming and worry about optimising later". What he's saying is that people optimise the wrong parts of the code at the wrong time. That in no way means you shouldn't spend some time thinking about your architecture to make sure it's efficient before you start writing code. You might prefer the other sentiment, but you shouldn't cite Knuth as a defender there. – Voo Nov 6 at 17:29
  • 19
    @R.Schmitz Back when Hoare/Knuth made that statement "optimization" meant cycle counting and other things we don't do today anymore anyhow, not "think about a good architecture before starting coding". Using the quote as an excuse to simply not think about good system design is simply not what they had in mind. – Voo Nov 6 at 20:41

Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?

The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.

You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.

What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?

You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.

Having grown attached to the project and the code I've already written,

I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.

The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.

If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?

If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).

I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.

That is a different problem for a different day.

First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.

But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.

Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.

To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.

I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.

The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.

For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.

The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.

I simply don't know any web frameworks, and don't know which one to start using.

The same problem arises here. The solution is not to think more, but rather to act:

  • Stop pondering the perfect answer.
  • Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
  • Use it.
  • Did you like using it? Was there anything you found annoying?
  • Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
  • Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.

To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.

but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over

Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.

Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.

  • 9
    Starting from scratch is rarely the right choice: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i – Martin Bonner Nov 6 at 13:29
  • 9
    @MartinBonner Whilst that's certainly true in the context that Joel talks about in that article, if this is literally the first project you've worked on, and you're the only person who's worked on it, then it's very possible that you will be able to write something better. I remember that I rewrote the first big-ish personal project I worked on, and this was probably the right decision at the time - the original prototype was broken beyond repair, because I didn't know what I was doing when I wrote it. – James_pic Nov 6 at 15:11
  • 4
    @Flater I agree with most of what has been written here, except one thing: if you're to choose a framework and you know nothing about any of them, you can at least check the adoption level of that framework. For example, how many stars does it have on github? How many issues are there? How many contributors? When was the last update? Answering these questions may at least help in choosing a framework for which you can get help, hire guys that know it better, etc. – Jalayn Nov 6 at 18:22
  • @Jalayn One would assume that a beginner who has no foreknowledge is likely to stumble on well-known frameworks to begin with. – Flater Nov 6 at 18:36
  • 3
    This is a great answer because it encourages a disciplined and methodical approach. It took me a number of years before I could fully appreciate advice like this! – kashiraja Nov 7 at 1:32

Despite the enormous amount of money Facebook and Google have poured into marketing to convince you otherwise, front end frameworks exist for two primary reasons:

  • First, offloading hardware/network demands to client-side operations by way of putting state and logic in the client
  • Second, pertinent to the additional client logic necessary to support the first point, they provide isolated execution contexts so that you can cram other people's code into a page without breaking anything.

You probably only need to reach for a framework to solve these problems if your application is inherently stateful, if the amount of application state you're saving client side is quite complex, if you expect a great many clients with bad network latency (mobile, or distant from server), or if there is a strong business need to support particularly advanced CSS or dynamic element creation.

Framework marketing wants you to believe that their special method of architecture increases development velocity and makes maintenance easier. This is patently untrue for small teams working on simple projects. Isolating code and organizing imports may help a large team bring a product to market more quickly. It provides much less for a single person development team working on an already functional project.

You will spend more time learning how to fit existing, functional code into the framework than you will actually implementing features, and chances are pretty good that someone somewhere will update something, and code written in that framework will cease to function inside of 18 months unless someone is there to constantly maintain it it.

Vanilla JS, and to a lesser but still significant extent JQuery, do not suffer from those problems. With some notable exceptions, JQuery + AJAX applications not relying on browser specific behaviors, and forgoing external dependencies where sensible, continue to work 10-15 years after they were originally written with very minor changes.

Frameworks are great for typical startups supporting ongoing, complex, publicly facing web applications. They let large teams co-ordinate well together, integrate nicely with vendor add frameworks, and support flashy new widgets and design paradigms to help you stay competitive.

None of that matters for a small software tool with a fixed audience that you're about to abandon. Taking on a framework both slows your development velocity as you adapt to a new paradigm, and introduces unnecessary compatibility risks. Keeping client side code simple, (and ideally self hosted) means that the surface area of compatibility risk drops significantly. Browsers will change, CDN urls will stop working, dependencies will go out of date - But nobody is touching that server, and it will keep working just fine.

Don't adopt a framework unless it solves a specific architectural problem you have today or can foresee soon, and strongly consider addressing that concern by another means instead if that is at all tenable.

  • 2
    When I think "framework" I think things like jQuery or Angular or React where it provides a lot of building blocks for things that would be annoying to implement yourself (and often tricky to implement correctly and cross-browser-compatible). – fluffy Nov 7 at 22:39
  • @fluffy What, specifically, do you think Angular or React do for you that's significantly easier than doing the same thing in vanilla JS or JQuery in 2018 on non-mobile browsers? FF / Chrome / Edge have more than enough common surface area to build fully functional, small apps on w/o shims these days. – Iron Gremlin Nov 8 at 17:39
  • 2
    @IronGremlin Are you kidding? Have you ever used two-way data bindings or Angular/Vue/whatever templates? For applications where these features are useful they are a huge simplification, and let you get rid of brittle event-based code. Next, CPU. Sure, using JS framework usually takes some load from the server, but it's purely a by-product, and you say it's the main reason for them. Next, "Simple architecture (...) seems a better fit for this project". Well, that's a pretty far-fetched statement, given how little we know about the project. – Frax Nov 8 at 19:27
  • 2
    I mean, you say your core point is "not everything needs to be or should be a 'rich js application'". I agree with this point. However, I think your answer fails to convey it properly - it would be much better if you edit it. – Frax Nov 9 at 7:36
  • 1
    I have never heard about offloading CPU to client as a reason to use JS - I'd say the historical trend of JS use on the client suggests just that (I am not saying THE (one, overriding) reason), and seemed to grow exponentially ever since jQuery sliced through the Gordian Knot of browser incompatibilities. – radarbob Nov 9 at 18:02

The best thing you can do to "future proof" your app is to follow best practices in the design of your system to maximize loose coupling and separation of concerns. There is no part of your app that is safe from becoming obsolete, but much you can do to isolate code that becomes obsolete for reason X from code that doesn't necessarily have to be impacted by X.

However, I would contend that your concern should be less for the growth/scalability of your app than the growth rate of your own experience and capabilities. The mental block you describe sounds to me like either learning stagnation or awareness of many known unknowns without the strategy or tools to tackle them.

Frameworks are not particularly well suited to solving the "future-proofing" challenge, though they can provide relevant initial guidance to the inexperienced, usually via high-level design patterns like MVC. Rather, they tend to be more useful as ways to accelerate development by providing strong cohesion and often at the expense of tighter coupling. For example, suppose you use some framework-provided object-relational mapping system throughout the app to interact with your database, complete with caching-system integration. Maybe later you need to switch to a non-relational datastore and now everything that uses it is affected.

The mess you now have didn't come from what you used, but where you used it (probably pretty much everywhere on the back-end). How much better off you'll be if the code which renders a page never fetches the data it renders.

Suppose you want to add some little widget to a page which requires extra scripts and resources to work properly. If you're using a framework, you can ask "How does it want me to add the dependencies to a page for this thing?" If you're not, then the question is more open-ended: "What technical concerns am I touching that should be somehow separated?" That question takes more experience to answer, but here are some hints:

  • What would happen if tomorrow you moved all your static resources (scripts, images, etc.) to a separate server, content delivery network, etc., or started trying to package them all together to improve performance?
  • What would happen if you started placing this widget on different pages, or multiple instances of it on the same page?
  • How might you start performing A-B testing on different versions of the widget?

If any of this sounds overwhelming, then I'd suggest you should use a framework for now, not so much for the sake of your app but the sake of your own personal growth. Don't necessarily start over though. Instead use frameworks as curriculum to help guide the evolution of your app.

There are only two ways to learn. One is by trial and error, and the other is by learning from experience of others. Trial and error cannot be eliminated. Software development is by its very nature a continuous learning field and any code that doesn't do something new or different is by definition unnecessary. (Instead use the code that is already written.)

The trick is to minimize it by proactively seeking out pre-existing knowledge (strategies, best practices, and code/libraries/frameworks) throughout every step of the development process so you do not find yourself constantly re-inventing the wheel.

As for the app you are currently writing, however, your first concern should be simply to get it done with a minimum of mundane effort (which is kind of like code smell, but for the development process). Given the nature of human learning, the fastest way to achieve high quality is to start out with something. It is far easier to understand the goal when you can shape it by critiquing something you already have.

If you can accept that much of the code you write is a disposable learning process and necessary to find good designs, that will helpfully motivate you to keep at it. After all, it's the challenge of problem solving that makes software development engaging, and that challenge is ever-present if what you're doing is worthwhile (see "continuous learning" statement above).

Above all else, "scrapping the thing and starting over" is never an option ... after all, didn't you say that you have "a half-dozen clients?" Have you yet paused to consider what they might think of your pronouncement, given that they are right now (presumably) "perfectly happy with your work?!"

Here's an analogy that I like to use:

  • "My job is to build houses for people to live in, for people to build businesses in, and so on." My job is to make "those impossibly-tiny, over-glorified bits of sand" to do useful work. (Just as house-builders craft homes from gypsum wallboard, ceramic tile, concrete block and 2x4's.)

  • However, whereas the "nails" that house-builders use really haven't changed much in two hundred years (except to go from "square" to "round," and then to be made useful with pneumatic nailing-machines), the technology that we use is ever-changing and sometimes undergoes very profound change. ("So it goes.")

  • "Nonetheless, each house, once built, will forever-after be lived in." You can't evict them. Once you build it and hand over the keys, "it's not 'your' house anymore." It is what it right-now is, and it will stand for a very long time.

A large part of my business these days is to help clients to cope with software that was built ten, twenty, thirty or more years ago, using the "state of the art" technologies that existed in those days – (and which, ahem, I remember) – and which are still in service(!) today.

Ensuring something is future proof is almost impossible. Checking that app is scalable is not too hard though. You just need to write some performance test for the app and see how many clients it can handle. Writing tests will definitely make your app more future proof because you will be able to gauge how app behaves after you implement more changes into it.

wrt framework, I wouldn't be too worried performance/scalability wise. This is something you can easily check and most likely fix. The bigger issue is security. Web frameworks usually help you write proper authentication code, cookies, CSRF protection, etc. Especially given your lack of experience, better focus in that area.

I started writing a comment about learning frameworks, but eventually it turned into something looking more like an answer, so here it is.

Not knowing any frameworks seems like an issue. In basically any webdev job you will need to work with some framework. Learning another framework after you know one is not that big deal, but learning the first one may take a while - which is why employers may care about that. Avoiding frameworks may indicate not invented here syndrome, which is widely impractical approach.

As the main point of knowing your first frameworks is to learn a common language, perhaps just try learning something popular among your peers. You may try modifying some simple project written in a framework. Starting a project from scratch in a framework you don't know is a very ineffective way of learning.

Now, your actual question was about a specific project and porting it to a framework. For that, the answer seems to be: it depends, and we can't really tell you. However, porting stuff to a framework you don't know is almost certainly a bad idea, as you can't even know if it makes sense. Hence, it seems that you should leave it as-is, and revisit this decision at some point, once you know and like some framework. Other answers contain good points about what you should look for when making such decision.

This article got a lot of attention on Hacker News 2.5 years ago: Write code that is easy to delete, not easy to extend. This perspective may or may not help you deal with your present codebase, but in the future, it could help prevent frustration that comes from perfectionism/over-engineering.

If we see ‘lines of code’ as ‘lines spent’, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.

I don’t need to tell you that deleting code is more fun than writing it.

(emphasis mine)

The article's thread on Hacker News might also be worth a read.

As far as making it future proof and applying scale & framework principles, it's a tall task to take on by yourself, I'd probably just not worry about it, but if you must:

Keep your code clean, follow SOLID, DRY principles > google.

Apply a load-balancer as soon as possible.

Stand up at least two web servers, handle load balancing scenarios in the code.

And last but not least, there's better stacks for handling a million users than LAMP, but I'm sure it's totally doable.

Case and point, see: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade The point is valid, but 10gb is trivial as a test subject.

protected by gnat Nov 7 at 7:25

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.