131–140 of 204 posts
Earlier quoted context omitted.
All JS frameworks will share some features. What specifically about Vue do you think is unnecessary or shows that the Vue team doesn't understand?
I'm guessing hooks, even react devs are not sure about the fake functional programming nonsense.
Earlier quoted context omitted.
All code is text. There is no pure "code" representation, text inside attributes being parsed as JS is no different than parsing text inside some tags. Also modern component-based JS frameworks all work the same way. The UI definition is a template that's compiled into a render function which produces the final output during runtime. Each framework uses different syntax: React uses JSX which is a domain specific lang…
> text inside attributes being parsed as JS is no different than parsing text inside some tags. It is different. Because "text inside script tags" is Javascript. Vue's templating syntax is a weird and inconsistent mishmash of custom DSL, Javascript subsets and Javascript expressions. And it also depends on when it's parsed.
Again, it’s all just text in different syntax. Programming languages are just a very large and well defined syntax compared to a template language, but that’s all it is.
Vue’s directives offer just enough control to handle 99% of scenarios while remaining within HTML.
I feel like I'm in an alien world when it comes to Vue - it has this weird pattern of making strings do loads of heavy lifting. The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me. Things like v-for="record in commits" to loop over something is insane to me - this isn't code, this is a string inside a html attribute! How can you get any sort of good type analys…
Yeah, this isn't really an issue; it's just a templating language. You can get an extension for your IDE to make it syntax highlight correctly. That's like saying a .js file is just a string. Um, yes I guess sure? All code is just a string. HTML is also just a string. Vue's HTML templating syntax is also just a string, but it's also code. It's code that's mainly HTML, with certain spots that allow full JavaScript. An…
Beautiful. Vue is the future, any other framework, specially React, isn't
Without making any judgement as to which is better, I'm afraid that's all in your head, bro.
Earlier quoted context omitted.
All JS frameworks will share some features. What specifically about Vue do you think is unnecessary or shows that the Vue team doesn't understand?
I'm guessing hooks, even react devs are not sure about the fake functional programming nonsense.
In fact, many Vue projects are using composition Api in Vue2 via a plugin because it is so good.
Earlier quoted context omitted.
I cannot relate to this experience at all. Can you specify examples of what you're talking about?
not OP but 4 examples I've faced recently: - facebook used to maintain CSSTransition for animation but dropped support for it and gave it to a dude who broke not only the public API but also some features I was relying on. I'm left having to recreate all the animation in a different lib, meh - lifecycles related deprecation: componentWillMount, componentWillReceiveProps, componentWillUpdate. My app used to have a lot…
Earlier quoted context omitted.
> text inside attributes being parsed as JS is no different than parsing text inside some tags. It is different. Because "text inside script tags" is Javascript. Vue's templating syntax is a weird and inconsistent mishmash of custom DSL, Javascript subsets and Javascript expressions. And it also depends on when it's parsed.
Text inside script tags is parsed as JavaScript by default. It can be other languages too, like typescript inside a .Vue file. Again, it’s all just text in different syntax. Programming languages are just a very large and well defined syntax compared to a template language, but that’s all it is. Vue’s directives offer just enough control to handle 99% of scenarios while remaining within HTML.
It can be, but usually isn't.
> Again, it’s all just text in different syntax.
Again, it's not. And the reason is simple: the browser literally knows nothing about other syntaxes but Javascript [1]
So, no, "text in Vue" is literally not the same as "text in script tags". It is a mish-mash of:
- Vue's own DSL (see v-for)
- JS expressions that are wrapped in some scope (see v-if)
- JS-like DSL where function cals are not function calls, there are magic vars, but objects are also fine (see v-on)
- Maybe JS expressions in v-bind? But depends on the attribute name? Can use string concatenation, but anything else?
- Actual JS expressions in {{}} which can't be used just anywhere... but then these expressions can have pipes into filters in them? And filters once again are JS-like, but are not
None of this has any coherent specification, and we rely on Vue to properly parse and break it down into actual Javascript code that can then be included in a tag.
Edit: I had the same laundry list of things for Svelte before Svelte 2, but Svelte 3 is significantly more consistent and coherent in what it expects in a template.
[1] There are ways to make it know other syntaxes, but that is rare and has largely fallen out of favor.
Earlier quoted context omitted.
would you have preferred {{ for item in items | orderBy 'field' -1 }} ? I feel like you're getting hung-up on the fact that the template directive is also a valid attribute and not something similar to jinja - but that's just syntax
I don't really see much of a difference - that is still storing it as a text attribute inside a DOM node. To be clear, I vastly prefer Reacts approach of putting HTML into JS, rather than Vue/Angulars approach of putting JS into HTML.
Both approaches are valid, and each comes with its own set of tradeoffs.
Congratulations to the Vue team, this is definitely a big win for them. Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM. And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices h…
Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years). Oh boy I was wrong. Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially wh…
Forget a dependency in the dependencies array, forget an useMemo or a useCallback and your application will rerender like crazy.
Yes, it looks nice from the point of view of understanding the code, but what actually happens at runtime and the amount of miss steps they can produce is astounding.
Nowadays I'm using Vue and it is way, way easier to deal with due to the reactivity model.
Vue's deprecation process is still a big problem in my view. Migration from Vue 2 to 3 is a painful one, while React doesn't have this problem. You can argue that component writing practices have changed over the past years in React, but the old ones all still work, while Vue 2 components just don't work in 3.
EvanYou's comments about a future "compatibility build" for 3 that works with 2 is honestly still a bit worrying. I'm glad it exists but it just so easily convinced them. Is there going to be a performance penalty? Will it all work out of the box?