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

Vue.js vs. React

vuejs.org

Post reply on HN
Print view View original

441–450 of 486 posts

Re: Vue.js vs. React

#441

Post by harunurhan »

a13n wrote: post #46

You'll see quotes in this thread like "The demand for both React and Vue.js is growing tremendously" thrown around. It's good to check out npm install stats to get an unopinionated comparison. https://npm-stat.com/charts.html?package=react&package=vue&p... In reality, React is downloaded roughly 4-5x more than angular and 7-8x more than Vue. In August so far, React has 75% market share among these three libs. Interes…

I would also check this

https://insights.stackoverflow.com/trends?tags=angular%2Crea...

Re: Vue.js vs. React

#442

Post by tigershark »

nartubio wrote: post #432
tigershark wrote: post #406

Earlier quoted context omitted.

You can't compare react and vue with pizza and pasta. Pizza and pasta are two finished products, while react and vue are two different ways of building the same product. Your comparison doesn't make sense at all to me.

Say you're about to cook pizza or pasta, you use flour and tomato for both. Comparison not 100% off IMO.

No. 1000 times no. For the pizza base you use flour, water, salt and yeast. For fresh pasta most of the time you use flour and eggs. The process moreover is completely different. You NEVER use tomato for making the fresh pasta or the pizza base. You may use tomato as a condiment for pasta and pizza. This comparison is even more wrong than comparing apples and oranges. But I expect that unlike me you never cooked pizza and fresh pasta if you can't see the obvious difference.

Re: Vue.js vs. React

#443

Post by tycho01 »

Dunno if it's just me, but I read these Vue articles and all I see is a bunch of hypocrites with an identity crisis, criticizing React for fragmentation, Angular for having 'one Right Way'. So they're better than React for offering one Right Way, then they're better than Angular for offering fragmentation? I mean, jeez, pick one stance and stick with it.

Re: Vue.js vs. React

#444

Post by unclebucknasty »

jcoffland wrote: post #410
unclebucknasty wrote: post #270

Earlier quoted context omitted.

> I can at least remember six template engines' syntax I've learned... TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language. Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options. I think the intense UI-demands of progres…

Sounds like you want Visual Basic.

I've never worked in VB, but I've compared the concept to Swing for Web apps.

Re: Vue.js vs. React

#445

Post by tigershark »

batiste wrote: post #431
tigershark wrote: post #429

Earlier quoted context omitted.

I think I understand it quite well having worked for more than a decade on complex systems. I can't say the same for you if you think that putting some logic in the presentation layer like the example above is a good thing. I would always transform my domain in the model object while the presentation layer should only present the transformed model. Using a map function directly in JSX is a sure recipe for disaster in…

He is right taught. You are allowed to have all the logic you want in your presentation layer. As long as it is presentation logic this perfect. If it is "Business logic" then this is wrong. Have you realised than having a if statement is already "logic"? Template system that don't have if statement are absolute trash IMHO.

Ah ok. So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong. I don't know Vue.js, but in WPF I would have simply bound an ItemsConttol to the list of models. Stop. Finished. No presentation logic at all in the XAML file. WPF will automatically bind the correct DataTemplate to the specific ViewModel contained in the list. I would have never ever approved a pull request in which someone implemented that using a monstrosity similar to the one shown in this thread. The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model. Reading this thread, apparently in React is encouraged to do whatever sh@t you want directly in the JSX file rather than delegating it to where it belongs. Heck, you are even excited that JSX is Turing complete, as if it was a good thing. I will continue happily to write my code respecting the separation of concerns, leaving all the logic out of the XAML or HTML. You are free to continue to put everything in the JSX if you like it, but don't expect me to stay silent when you mislead many people in thinking that writing logic in JSX is the right way to go.

Re: Vue.js vs. React

#446

Post by unclebucknasty »

meredydd wrote: post #421
unclebucknasty wrote: post #270

Earlier quoted context omitted.

> I can at least remember six template engines' syntax I've learned... TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language. Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options. I think the intense UI-demands of progres…

This is exactly what we're aiming for with https://anvil.works . We have a components+properties model, driven in Python, which gets translated to HTML+JS+CSS. We also have a visual editor, and abstractions over a bunch of the client-server stuff that's typically icky on the Web. The challenge of such a system is that the web platform is so huge and sprawling, and constantly growing - and all of it's written in JS/HT…

Very interesting. Yes, at a glance, that's exactly what I had in mind.

>the web platform is so huge and sprawling, and constantly growing

>we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch

Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have to open the escape hatch, I can plug a resulting component back into the framework (lay it out and set properties in the visual editor, etc.), that might be even more optimal. Either way, I'd rather a framework do the heavy lifting and let me deal with the edge cases than me do all of the heavy lifting and plumbing, so that's a win.

>and all of it's written in JS/HTML

And, this is the part where I do have to scratch my head a little. I'm going to guess you've heard this question 4,321,257 times, but why not support JS? It is the lingua franca of the Web (as your quote acknowledges) for better or worse, and virtually all devs already know it. There's also a rich JS library ecosystem.

The idea that I have to pick up Python just to try it out introduces more friction. I'm guessing that might slow adoption with a huge percentage of your potential audience who might otherwise have the knowledge they need to jump right in.

Re: Vue.js vs. React

#447

Post by meredydd »

unclebucknasty wrote: post #446
meredydd wrote: post #421

Earlier quoted context omitted.

This is exactly what we're aiming for with https://anvil.works . We have a components+properties model, driven in Python, which gets translated to HTML+JS+CSS. We also have a visual editor, and abstractions over a bunch of the client-server stuff that's typically icky on the Web. The challenge of such a system is that the web platform is so huge and sprawling, and constantly growing - and all of it's written in JS/HT…

Very interesting. Yes, at a glance, that's exactly what I had in mind. > the web platform is so huge and sprawling, and constantly growing > we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have t…

> Yes, at a glance, that's exactly what I had in mind.

Thrilled to hear it! If you do try it in more depth, please do drop me a line (email in my profile).

> why not support JS?

Two reasons:

1. Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves. People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS and all these other pieces, as well as this new framework, and you've done the opposite of simplifying web development. This is the "Javascript Framework of the Week" failure mode.

2. Contrary to your assertion, "most devs" don't actually know JS. It's something people only learn because they're learning front-end web development, and it's difficult to learn it without the whole HTML/CSS/frameworks hairball. Python is much friendlier to, eg, data scientists or embedded programmers or back-end developers, who have every right to think they should be able to put together a web app without learning three new programming languages and two new frameworks.

(This is another way of putting what I said earlier about "prioritising usability for non-web devs".)

Re: Vue.js vs. React

#449

Post by unclebucknasty »

meredydd wrote: post #447
unclebucknasty wrote: post #446

Earlier quoted context omitted.

Very interesting. Yes, at a glance, that's exactly what I had in mind. > the web platform is so huge and sprawling, and constantly growing > we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have t…

> Yes, at a glance, that's exactly what I had in mind. Thrilled to hear it! If you do try it in more depth, please do drop me a line (email in my profile). > why not support JS? Two reasons: 1. Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves. People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to kno…

>Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves.

I see. Kind of a purist approach that eliminates all temptation by not offering the option to go there. Sound reasoning, as JS definitely has slippery-slope potential.

>People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS

I'm probably too biased to make a call on this. I'm so wanting to be released from that madness that I'd fight tooth-and-nail not to descend back into it.

So, I look at it the other way around: My JS would be more disciplined (and there'd be les of it), as I'd be released from the need to use it so much for stuff like DOM handling. In my ideal world, I wouldn't even know there was a DOM or HTML or CSS. I'd just use JS in event handling and, perhaps, functionality that directly supports the same.

>"most devs" don't actually know JS...people only learn because they're learning front-end web development

That's what I intended--that most web devs know JS--as I was speaking in the context of web development.

But, I missed the emphasis on the "non-Web devs" portion of your statement. I do get that and applaud you for staying with your focus. The product has to have a market and an identity. OTOH, it feels so close for guys like me in the Web dev world who know there's a better way!

>please do drop me a line (email in my profile).

Will do. And will try to reserve any web-dev specific comments. :)

Re: Vue.js vs. React

#450

Post by hunterxg »

steinuil wrote: post #94
mediumdeviation wrote: post #79

Earlier quoted context omitted.

JSX is closer to JS than HTML, which means it annoying to write in some cases. Quick, what does this render as? Link 1 | Link 2 | Link 3 It's not Link 1 | Link 2 | Link 3 as you'd expect - instead, the whitespace after the pipe character is eaten by JSX. This is because HTML is whitespace sensitive, but JS is not, and so to allow indentation, JSX trims whitespace. Here's another - { Object.entries(definitions).map(([…

Good point about the whitespace, but I'd still rather have the templates inside my code than separate the two, mentally parsing two separate languages with different syntax and stitching them together is a lot more mental overhead IMO.

Your not mentally parsing two languages. Your parsing business logic in js and templating in regular html.

You still have to understand html inside weird jsx code...

Post reply on HN