Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

To me this kind of thinking sounds so strange.

A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases.

Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework.

And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product?

If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway.

However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do.

Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)

> They are going to do a better job of designing a framework than you will in most cases.

My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit my needs better than theirs will, each and every single time.

>If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one.

Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one-size-fits-all thing. I don't want to deal with upgrades that are not backward-compatible. I don't want to spend days debugging someone else's to figure out what I did wrong.

> Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases.

I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons.

It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.

If time isn't the main factor, then by all means you have the right idea! But I've never really been in a situation where I can afford the time and manpower to do everything myself, so my view is skewed by that.

And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it.

Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect.

I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.

Yes, frameworks are tools, but they're typically overspecialized and poorly designed. If vanilla JS is a cnc machine, Angular is an injection mold for a toy truck. If you're building a toy truck, that's awesome.

If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.

That metaphor doesn't help with the default thinking behind a large proportion of engineering decisions.

It goes like this:

    This is hard
    
        =>  I want to do one or two slightly different things
    
            =>  Building custom things feels like valuable work
    
                =>  Use the CNC machine!

This is exactly the thinking that created the Juicero[1] (which actually uses many CNC parts), and we all make fun of them even though the same process is a huge driver behind decisions everywhere. It's like an engineering strawman. Create engineering problems because those are easier than actually building the thing.

The word 'overspecialized' is a bit sour for web frameworks. There are billions of web sites, most of which are astoundingly similar. Squint at the front-end UI and most engineers are basically building Asana, over and over again, like a boot stamping on a human face – forever. The ways they are differentiated are generally not related to code at all, instead business or meta-engineering needs (e.g. NYT dataviz graphics production, or a small team trying to maximize output).

In contrast, everyone needs a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things. If you think Angular (which, stripped down, is ~20kb gz and very basic indeed), or really any framework is too specialized for some set of needs which includes the above four things, you are attacking a very frightened-looking scarecrow with the might of the U.S. Navy. Framework churn is part of this problem; people think they have such big engineering tasks ahead only the new shiny thing can solve it.

The point is, needing the whole CNC is _very rare_. Anyone who thinks that all of the big or even little front-end frameworks are too specialized should go look in the mirror. If, when you do that, you literally see a company with 300 engineers or incredibly specialized needs – like immersive interactive media, or you need IE6 compat, then go build your crazy stuff while the rest of us churn out decent apps with near-zero friction.

[1]: https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensi...

But Angular isn't simply "a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things". That's JQuery you're describing. Angular determines the shape of the extensions you can build for it, and general, standard components don't fit its philosophy out of the box.

With the cnc, you can pick parts and modules from a much bigger pool, then cut your enclosure to match. A widgetized, self-contained module is much easier to adapt to a particular use than a framework, for the same end result.

I can't say I agree that a library any easier to use within or outside of a framework.

No matter what if you are using 3rd party libraries you will be writing some "glue". You will need to hook into their API and have it work in your application. Yes frameworks tend to enforce a structure on what that API has to look like (at least from a macro view), but that's a pro of them, not a con, and it's almost never "required" (you could just as easily use the library directly. If you can build a "connector", then you can use it directly whenever needed if it's not much code).

Yes, you may need to write more adapter code than you would if you weren't using a restrictive framework, but once written that "adapter" can be treated like a widgetized self-contained module. And it's instantly understandable to the rest of your dev team because it acts just like the other components/widgets in your codebase, using the same data flow, using the same UI system, etc...

If you're having trouble integrating a library into your framework, then the library is probably the one that's poorly designed. I say this as the 'maintainer' for ng2-dragula (glue code for dragula), which is equally great and terrible.

Great: the dragula library handles lots of common drag/drop patterns.

Not great: it relies 100% on the jQuery model of 'truth in the DOM', and the glue code makes a feeble attempt at flipping that around. When you drag, it literally moves the element and notifies you that it has done so. If you want to customize it, you reply to callbacks that give you the literal elements, and maybe read a data-attr off them. The glue code can automatically mutate an array to match what happened in the DOM, which has been an unmitigated disaster judging by the hundreds of GitHub issues mostly about this one thing.

The problem isn't the restrictive framework that doesn't let you do what you want, it's the API that's not designed for rendering from a non-DOM data model. If you ask 'would it be easier with vanillaJS?' the answer is no – it would still be a stupid way to write drag and drop code, unless you were coding your vanillaJS in an equally abhorrent way.

It will be harder if the parts and modules use ad-hoc specifications instead of adhering to some common framework (e.g. 5v or 3.3v power levels, imperial or metric sizing for drive axles, mounting screws, etc.).

Reply on news.ycombinator.com