Imagvue: An image processing component for Vue.js | Hacker News Reader

Imagvue: An image processing component for Vue.js

github.com

56 pointsrunkids17 comments

Super cool! I do wish it would be released as two libraries though. One in pure JS that does the image manipulation. And another that binds the base library to Vue. Would make it more broadly useful.

Pretty cool

How is it related to Vue?

If it depends on Vue, I wonder why. Why would it need Vue?

Well, because it's a Vue component?

What is Vue specific about it? Looking through the code, I don't see anything.

It's a Vue component, how is that not Vue specific? - https://github.com/runkids/Imagvue/blob/master/src/imagvue.j...

But what advantages does a Vue component offer over just doing the same thing with CSS? It's not going to be any more performant because it's not addressing a part of the rendering engine that Vue has any influence over. And you're not saving keystrokes because you've still got to instantiate the component and pass values to the props. All it does as far as I can tell is abstract away something that's trivial to do manually.

Vue components are structured in such a way (props, methods, data, computed properties, etc.) which is the same of the file you can find within the SRC folder of the project.

Yeah but why? It's just applying CSS. You set the props, it applies those props as CSS. Why not cut out the middle man and just apply the css directly? And why is lazy loading bundled in? What's that got to do with image processing?

Why not cut out the middle man and just apply the css directly Well one could extend this and argue that there's not need for frontend frameworks as you can manipulate the dom directly. Two way data binding is awesome.

I have no idea about the lazy loading. And yeah, it's "kind of image processing".

No. It makes sense to use a library that implements a VDOM and efficient Dom Diffing because that's hard to implement yourself.

And there is no need for front end frameworks at all. They should be avoided entirely.

And two way data binding is for fools.

Well, if you think that, why are you arguing over a submission about a component for one of those frameworks? You think it's useless just because you don't use something like Vue?

I'm not sure if you're trolling or not at this point.

You don’t have to use Vue as a framework. You can opt just to use the view layer as a library.

Vue implements a vdom, but never mind.

This comment is so subjective and unsubstantiated that it hurts the reputation of HN of having high quality comments.

> And two way data binding is for fools.

Pretty sure that this is against the HN guidelines. Please read them [1].

[1]: https://news.ycombinator.com/newsguidelines.html

I wasn't saying "don't use Vue", I was saying there are good reasons to use a view layer library, and I used "VDOM" as a relevant example specifically because Vue implements one.

And two way data bindings are the best way to make a code base inscrutable. I'll put it another way. Wise developers avoid two way data bindings.

Nothing special here, just css filters.

    blur(0px) contrast(100%) brightness(228%) grayscale(25%) hue-rotate(151deg) opacity(100%) invert(0%) saturate(100%) sepia(0%) drop-shadow(rgb(84, 191, 142) 16px 16px 10px)

https://www.w3schools.com/cssref/css3_pr_filter.asp

I agree, this doesn’t need to be a Vue component t. I looked through the source and it seems to be pretty poorly factored code that transforms inputs to css. I wouldn’t recommend using this library as the code seems to be somewhat hacky.

For example, it has lazy loading which is already questionable - why would you want that in an image processing library? But the way it checks this is to see that you are putting one transition group into the component. Why not have a prop that turns it on? I don’t think there is a reason - I think this developer is rather inexperienced.

Reply on news.ycombinator.com