6 ms·

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. An

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.

Klathmon 9y ago
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...
- cormacrelf 9y ago
  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.
ummonk 9y ago
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.).

Klathmon 9y ago

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...

cormacrelf 9y ago
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.

ummonk 9y ago

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.).