Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js is Wikimedia Foundation's future JavaScript framework

lists.wikimedia.org

Post reply on HN
Print view View original

171–180 of 204 posts

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#171

Post by ratww »

flowerlad wrote: post #161
ratww wrote: post #46

Earlier quoted context omitted.

I suggest searching what each of those HOCs is doing. This code is not dealing with routing, fetching, managing state or rendering. It is merely "gluing" those things together. Doing that can be considered a "single concern". Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at. Also notice there's a disclaimer on your linked article here the author…

> It is merely "gluing" those things together. That's pretty bad if you need "glue". > Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at. React is a UI technology, and only your view layer should know about the React stack. The model layer should be UI-technology agnostic (includes avoiding Redux etc.) and so should most of the controller layer.…

Once again, I suggest that you search what each of those HOCs is doing.

These functions are not part of what would be a controller or model layer in MVC. This code is not dealing with routing, fetching, managing state or rendering. They are merely gluing complex data coming from these other parts of the system into what is the view layer here. The logical separation still exists!

Sure OP could reimplement all of them by hand, but ultimately it doesn't matter: the code is still properly separated in the way you're mentioning. Libraries like those are free to have functions operating in multiple concerns, as long as the logical separation still exists, which it does.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#172

Post by zkldi »

manigandham wrote: post #169
dmitriid wrote: post #168

Earlier quoted context omitted.

> The point is that all code starts as simple text, and is parsed and compiled into some lower layer Yup > What actually does the compilation is irrelevant. Nope. It is relevant. For the stuff you put between script tags there's at the very least https://github.com/tc39/ecma262 that you can look at and tell exactly what's going on with your code. With Vue (and, yes, React and Svelte and Angular): who knows? It might…

The topic is that all code is text, and everything can be parsed and understood based on specific language grammars, even if they're embedded within each other. What are you even arguing at this point? This isn't about compilation or strings anymore. You don't like Vue's specific DSL? Or you don't understand it? Or you found a problem with the documentation? Or do you need a full grammar and syntax definition before…

> It's basically any valid `for..in/of` expression

This isn't true at all though, because `for x in y` is invalid JS.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#173

Post by buchanaf »

seph-reed wrote: post #75
gentleman11 wrote: post #68

Earlier quoted context omitted.

By tweening and animation, you mean shifting an element from one part of the screen to another? What part of react fights against this? I’ve been using react for 3 weeks and I’m just curious what I might run into later on

If you're animating using just css classes (or transitions), you'll be fine. Some animations need to be run in javascript though, and doing that through state is a bad idea. You can use ref, and sometimes that's fine, but if the data is changing (hitting a moving target), then you need communication. Think coach-marks and scrolling at the same time. And "tweening" views means showing the last view fade out while the…

Really the trick is to use react-spring or react-transition-group and leverage powerful community tools that have solved these complex use cases.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#174

Post by manigandham »

zkldi wrote: post #172
manigandham wrote: post #169

Earlier quoted context omitted.

The topic is that all code is text, and everything can be parsed and understood based on specific language grammars, even if they're embedded within each other. What are you even arguing at this point? This isn't about compilation or strings anymore. You don't like Vue's specific DSL? Or you don't understand it? Or you found a problem with the documentation? Or do you need a full grammar and syntax definition before…

> It's basically any valid `for..in/of` expression This isn't true at all though, because `for x in y` is invalid JS.

How is it invalid? Here's the syntax about a for..in loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

   for (variable in object) {
     statement
   }
The only difference in Vue is not having to explicitly declare the variable. But so what?

You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string isn't the same syntax as JS" but I don't see what the point is. Why does it have to be valid JS?

Again, you can embed syntax within each other just fine. JSX has HTML tags inside JS. HTML has tags like and for other languages (regardless of what the default language is or what parses it).

So, for the last time, what's the actual argument?

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#175

Post by codethief »

seph-reed wrote: post #75
gentleman11 wrote: post #68

Earlier quoted context omitted.

By tweening and animation, you mean shifting an element from one part of the screen to another? What part of react fights against this? I’ve been using react for 3 weeks and I’m just curious what I might run into later on

If you're animating using just css classes (or transitions), you'll be fine. Some animations need to be run in javascript though, and doing that through state is a bad idea. You can use ref, and sometimes that's fine, but if the data is changing (hitting a moving target), then you need communication. Think coach-marks and scrolling at the same time. And "tweening" views means showing the last view fade out while the…

> The trick is to recycle your html elements, but it'll fight you for it.

No, the trick is not to use React for animations in the first place.

It's simply not a good a idea to use regular React state for very short-lived data (like animation state) as React will end up re-rendering everything all the time, leading to a significant performance penalty. Instead, I would rather decouple the animated DOM elements from React's state & change handling and just use e.g. d3 to control them. (Yes, it's not pretty but animations have never been pretty in the first place.)

Speaking of (not) using React for short-lived data, this reminds me of another common pitfall: Forms. Many tutorials online blindly recommend binding every HTML input's value to a React state variable using onChange, usually causing the entire form to get re-rendered upon every single key press(!) No wonder the Web is so slow these days…

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#176

Post by codethief »

> - Deciding on Vue 2 or Vue 3 including transition path

Am I the only one here who absolutely hates Vue 2? No TypeScript support and no type safety at all (neither for props, nor for events, nor for provide/inject); many identifiers and references are hard-coded strings, making it very hard to discover dependencies between different parts of the code; `this` gets implicitly populated with props, data, computed, methods all at the same time and in some order that still escapes me; refactoring support even in IntelliJ/WebStorm is full of bugs (hardly a surprise given the missing type safety); horrible documentation ("Here's an example" != documentation); no proper two-way binding (i.e. one that doesn't produce change detection cycles). I could go on and on and on…

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#177

Post by sativallday »

hardwaresofton wrote: post #71
sativallday wrote: post #36

Love Vue. Polymer 2.0 with its HTML imports still offered a better DX in my opinion. Svelte offers a better DX than both of those frameworks. I don't even bother with FE anymore, more focused on BE/infra - but Svelte is always a pleasure to work in.

Btw if you liked Polymer 2.0/3.0 you may also like Lit (formerly lit-element)[0]. It has a less "proven" ecosystem around state/async action management and some other concerns (i.e. there's no redux/vuex), but the controller paradigm[1] looks pretty fresh and interesting. I'm of the belief that most of the time doing an async request or two and some caching and good architecture is enough for most app (not everyone n…

Lit doesn't have HTML imports.

This is why lit-element is nothing compared to Polymer with HTML imports: https://lit-element.polymer-project.org/guide/templates

DOM in JS is an anti-pattern from a DX perspective.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#178

Post by rank0 »

nsonha wrote: post #170
rank0 wrote: post #162

Earlier quoted context omitted.

The only UIs I create are pretty simple. For simple interfaces I would much rather deal with spaghetti and homegrown solutions rather than massive overhead and complicated abstractions. A lot of people just blindly build everything they write with their framework of choice. I argue that react is overkill for 9/10 web apps.

Where do they teach this "people do things because they're dumb, I'm special I see the truth" thing? Let me sign up.

Honestly if you just pay attention to the constantly shifting fads and “best practices” you’d have noticed by now.

Example: object oriented programming was THE WAY the write code a few years ago. Now functional programming is all the rage even though it has existed for decades. In fact, idiomatic react code just recently made the same switch.

I think it’s important to think critically and frankly having a discussion about the efficacy of contemporary design choices is the starting point.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#179

Post by lmm »

masklinn wrote: post #157
lmm wrote: post #141

Earlier quoted context omitted.

> People like templates, and the clear and declarative correspondence between input and output. You don't get that clear correspondence if you can have logic in your templates, and even supposedly simple expression languages in templates somehow always end up growing ifs, looping constructs and so on. Plain HTML fragments are good, but they need to be kept absolutely simple. > Wicket looks like absolute nonsense of t…

> You don't get that clear correspondence if you can have logic in your templates You absolutely do. > I don't understand your position at all. The problems of Struts and Spring are the problems of templates only more so - if I were to make a spectrum I'd have Struts (and Tapestry) at one end, Wicket (and hiccup) at the other, and traditional templates somewhere in the middle. The struts I got to use was full of "sma…

> The struts I got to use was full of "smart JSP custom tags"

Which is very much the opposite of how Wicket does things: there are no custom tags, the templates are inert HTML and there's a very small, non-customizable set of wicket tags/attributes (IMO the right way to do it is just IDs).

> That makes no sense whatsoever. Wicket and hiccup have nothing in common.

What they have in common is that all your logic is in code, not markup.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#180

Post by zkldi »

manigandham wrote: post #174
zkldi wrote: post #172

Earlier quoted context omitted.

> It's basically any valid `for..in/of` expression This isn't true at all though, because `for x in y` is invalid JS.

How is it invalid? Here's the syntax about a for..in loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for (variable in object) { statement } The only difference in Vue is not having to explicitly declare the variable. But so what? You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string i…

Because that loop doesn't do what you think it does?

for...in iterates over the keys of an object, but for in in vue iterates over the elements of an array.

Post reply on HN