Hacker News Reader

Comment by v13inc | Hacker News Reader

Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily.

Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.

View on HN

It goes both ways. By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved. For each feature you need, you either have to create your own solution, or manually integrate a bunch of smaller libraries. On the other hand, committing to an established framework means you have to work around issues that the framework was not designed to solve.

I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.

I agree there. Deciding on tooling for a long term project is a very tough balancing act.

Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.

Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.

Yeah, that's completely fair. I generally work on projects with constantly evolving requirements, so I tend to roll my own framework(s) by gluing together existing libraries that each solve a specific problem very well. That approach works well for me because most of the time I simply don't know the long-term implications of using an existing framework for any given project, so it's easier for me to evolve my own as I go. But I think there are a lot of projects out there that benefit greatly from the ecosystem behind certain frameworks (Rails comes to mind) and don't run into many bottlenecks due to said frameworks. For them, assembling a foundation is totally unnecessary because there's an open source framework that provides exactly what they need.

I don't have enough experience in different types of environments to say which approach is most suitable in most cases, but I'll definitely say that using an existing framework is the safer path (you have a community to lean back on), and is also advantageous for hiring. So I think you're correct when you say that many developers are afraid of rolling their own frameworks, but I think there are good reasons for that, especially for quickly-growing startups.

I couldn't have said it better myself :)

One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.

> the more complex and unique your problems are, the more it makes sense to roll your own.

Of course, everyone thinks their problems are complex and unique.

How many data points do you need to uniquely represent every person in earth? I bet its a smaller number then the number of constraints and requirements in your system.

By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved.

You don't have to roll your own framework. You could always just use the micro-libraries that are ubiquitous in JS and pick an architecture that best fits your application. shrug to each their own. :)

Isn't that basically rolling your own framework? :) A "framework" doesn't have to be a huge 100k-LOC library--it can just be a set of conventions and design patterns with some code to enforce them--but you always need some kind of consistent structure in your application if you want it to be at all maintainable.

Isn't that basically rolling your own framework? :)

shrug Personally, I don't see it that way. Frameworks are more generalized and reusable. They tend to be so large because they have to take into account a wider degree of problems. Applications with custom architectures and some external libraries are very specific and not typically reusable. Maybe it's just a matter of degrees.

No, because a framework tells you where to put your code. It will say "put a handlebars file in application.hbs, this is the default, or you can override the default and load it manually" or something to this effect.

So a framework has that "convention over configuration" flavor, while libraries are explicit. You actually have to load the application.hbs file manually with a handlebars parser. Then you use another library for the router, etc.

Maybe we have different definitions for what a framework is, but I strongly disagree with the notion that frameworks have to be implicit and magical. Libraries solve specific problems; frameworks help you structure your code. That doesn't mean that your framework needs to automatically load files named a certain way, or magically call certain methods; it can just be a set of conventions that are optionally enforced by code.

I can't imagine the spaghetti that would result from not using any framework (even a tiny handmade one) and just throwing a bunch of libraries together.

What? By your definition object orientation is a "framework" because it "helps you structure code" and is "a set of conventions that are optionally enforced by code". That's not a framework, that's a paradigm!

If a framework doesn't do something implicitly it's just a large library. If it's a set of conventions not backed by baked-in logic, it's a style guide.

A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.

If the framework never calls your code and you only call into the framework, that's always just a library. I would argue that actually it's easier to conflate a very full-featured library with a microframework because both really kind of call your code (especially when it's in the form of closures or a DSL).

You would never accidentally call a framework a library, though, because it's obvious that it's handling things for you. It's running everything behind the scenes and you just kind of advise it to do the things you want.

I really like this description. I've been trying to come up with a better description of what a framework is and isn't and I kept falling short. This one works well. Thanks! :)

Reply on news.ycombinator.com