Comment by cormacrelf | Hacker News Reader

Comment by cormacrelf | Hacker News Reader

Parent Full thread

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