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

Vue.js 3

github.com

Post reply on HN
Print view View original

111–120 of 308 posts

Re: Vue.js 3

#111

Post by TekMol »

Exuma wrote: post #104
TekMol wrote: post #97

Earlier quoted context omitted.

Nothing you describe is easier solved with Vue then with a templating engine. You can have a "DropdownMenu" template, feed it the data (which you call "state") and update the according element on screen just fine.

What do you mean by 'templating engine'. Give me a specific example. Templating engines to me are like handlebars... do you have a sample code example?

Say a function changes the cars array. All it has to do to update the DOM is:

document.querySelector('#carsDropdown').innerHTML=droppy(cars);

Where droppy is a HandleBars template that on page load has been initialized with the html that makes your fancy dropdown menu.

Re: Vue.js 3

#112

Post by Exuma »

TekMol wrote: post #111
Exuma wrote: post #104

Earlier quoted context omitted.

What do you mean by 'templating engine'. Give me a specific example. Templating engines to me are like handlebars... do you have a sample code example?

Say a function changes the cars array. All it has to do to update the DOM is: document.querySelector('#carsDropdown').innerHTML=droppy(cars); Where droppy is a HandleBars template that on page load has been initialized with the html that makes your fancy dropdown menu.

Yes, you are definitely missing the point of component based frameworks. That strategy is not even remotely scalable when you have nested complex state chains that vary slightly across multiple implementations of the same component, as well as 2-way communication with the original source of the state (from form inputs, and other parts of the UI).

Each UI action in google analytics affects some other part of the UI. If you change a filter in one area, it might disable sorting in another, and simultaneously change the calendar to be only You want the logic for those components to be IN THE COMPONENT. With your strategy youre putting all NON business logic and trying to account for "every possible scenario" which is the exact purpose of what reactivity does. You're not writing 1000 extra lines of code to account for every single possible combination (which can be hundreds in complex apps). Instead you quite literally write 0 lines of code, because the reactivity is handled (both ways)

Re: Vue.js 3

#113

Post by IshKebab »

Udik wrote: post #52
IshKebab wrote: post #30

I was hoping for better Typescript support for typing properties, since that is where 90% of our type errors occur. But it seems like you still have to specify the types manually. The example from the manual: const Component = defineComponent({ props: { name: String, success: { type: String }, callback: { type: Function as PropType void> }, message: { type: Object as PropType , required: true, validator(message: Comp…

You can use vue-class-component and vue-property-decorator as described here: https://class-component.vuejs.org/ You get to define your components as classes with their methods and properties, and can declare props and watchers via decorators. Overall a good typescript experience.

That is what I currently do. It's ok within a component, but there's no type checking when another component uses yours and gets the prop types wrong.

Re: Vue.js 3

#114

Post by zwieback »

good timing. I'm about to start learning vue.js so I'll start with this. We'll see how long it takes to "unlearn" 40 years of traditional programming and jump into the world of web apps.

Re: Vue.js 3

#115

Post by erokar »

LocalPCGuy wrote: post #109
erokar wrote: post #98

Earlier quoted context omitted.

Angular seems to be dying. Svelte is an interesting contender. I think it will be React's main competitor given a year or two.

This is a popular opinion particularly if all someone pays attention to is Twitter and Reddit but I'd argue it is a wrong opinion. Angular is alive and well, and being used/adopted every day for projects no one hears about. It isn't the "sexy" choice, but it is the one a lot of companies make. And if you're gonna point to opinion polls, and all kinds of respect to those who put them out, but they have a hard time cap…

Depends where you live and work I suppose. I used to work in a consultancy firm in Norway that was all in on Angular two-three years ago. Angular has been very popular in enterprise here. But Twitter and Reddit reach enterprise too in the end. The consultancy firm has now switched more or less entirely over to React because Angular is so out of vogue.

Re: Vue.js 3

#116

Post by holtalanm »

infogulch wrote: post #71
tyingq wrote: post #11

Earlier quoted context omitted.

It's definitely not how to show that, but if you follow their link ( https://docs.google.com/spreadsheets/d/1VJFx-kQ4KjJmnpDXIEai... ), you'll see the numbers. The math is like, if it did use 100mb, and now it uses 25mb, that's 300% less, because 25mb is the "100%", and you reduced by that amount 3 times. Odd.

These "75%"/"300%" numbers are ridiculous, the two numbers are calculated completely differently. At least be consistent. 100/25-1 = +3 = 300% increase 25/100-1 = -0.92 = 92% decrease

i think your math is wrong, bud.

100/25-1 = 3 (300% increase)

25/100-1 = -0.75 (75% decrease).

Re: Vue.js 3

#117

Post by IshKebab »

EvanYou wrote: post #44
IshKebab wrote: post #30

I was hoping for better Typescript support for typing properties, since that is where 90% of our type errors occur. But it seems like you still have to specify the types manually. The example from the manual: const Component = defineComponent({ props: { name: String, success: { type: String }, callback: { type: Function as PropType void> }, message: { type: Object as PropType , required: true, validator(message: Comp…

It's not that we can't implement it like that, the real challenge is in minimizing breakage from v2. We decided it's better to not completely alter how props are declared because that would be too much breakage. Instead, there's the compiler-based approach with ` `: https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX... (runtime props definitions auto-generated from TS interface)

But if the prop definitions are generated at runtime that means Typescript can't check them at compile time surely? Better than Vue 2 I guess but still not as good as React.

Fair enough on not wanting to break things, but I still feel like it is Vue's second biggest flaw and worth breaking to fix.

Re: Vue.js 3

#118

Post by mixmastamyk »

selfmodruntime wrote: post #69
TekMol wrote: post #59

Earlier quoted context omitted.

I would neither need jQuery nor a templating engine to write Minesweeper.

It's great you applied your vanilla JS skills to his totally metaphorical example. I still don't get why it's okay for every other programming language to use the STL or huge dependencies, but doing so with javascript is frowned upon for some people. You wouldn't write a JSON parser yourself in CPP, you'd install something from conan or use the STL or boost for that. Why is it so bad to do the same with js?

Not the end of the world, but the client will have to download it.

Re: Vue.js 3

#119

Post by wishinghand »

jiofih wrote: post #73

> allows end users to shave off up to half of the runtime size via tree-shaking Doesn’t webpack support actual tree-shaking (not just modules) or is that still a Rollup-only feature? There should be little difference in size in importing packages vs files if tree-shaking is on.

It will on or after October 10th, which is when the next version of Webpack is slated to release.

Re: Vue.js 3

#120

Post by TekMol »

Exuma wrote: post #110
TekMol wrote: post #92

Earlier quoted context omitted.

The browser does supply a huge number of APIs. To set one of the Minesweeper tiles to bomb, you could do: tiles[x][y].className='bomb'; And you are done. The rendering will nicely take place according to what you defined in the CSS.

What are you talking about? You're just talking about simple class manipulation which has nothing to do with actual reactivity, especially 2-way data binding. How would you support that with your "templating engines" you keep mentioning, which to me doesn't mean anything at all, in my understanding of what a templating engine is like handlebars.

As I said, I would not use a template engine to write Minesweeper.
Post reply on HN