Live data from Hacker News

How we do Vue: one year later (2017)

about.gitlab.com

141–150 of 159 posts

Re: How we do Vue: one year later (2017)

#141

Earlier quoted context omitted.

And why would that not be correct, and what are the sources of your number?

Most probably because Vue is enormously popular in China and npm mirrors are mostly used in china.

https://npm.taobao.org/package/vue https://npm.taobao.org/package/react

Vue looks like it's about 1.8x more popular in China.

Re: How we do Vue: one year later (2017)

#142
The main argument why I am using Vue (especially) on a lot of side projects is that I am able to deliver faster and better software products to my customers. For small businesses, they rarely care with which framework you utilized to deliver the software. What they care for is that they know they are getting value out of their financial investment and that it could really help with their operations.

And the ease with which I am able to extend / scale / enhance the application within a very short notice is also one of the highest selling points of my choice. Majority of businesses equate time resources with $ and the faster they are able to utilize the software, the better their business becomes.

Re: How we do Vue: one year later (2017)

#144
post #76

Earlier quoted context omitted.

I've always found Redux to be an overcomplicated mess, whereas Vuex is quite simple and has a nice, logical flow. For those who think it's still too complex, I've heard that Pathify https://davestewart.github.io/vuex-pathify is a great solution.

I regret every line of Redux boilerplate I ever wrote before discovering MobX. MobX is now even more fantastic with the new proxy based implementation. Reading up on VueX.. Not really looking forward to having to use it over MobX.

> MobX is now even more fantastic with the new proxy based implementation.

What does this mean? I've used MobX in the past but curious what has changed with this.

Re: How we do Vue: one year later (2017)

#145

Earlier quoted context omitted.

> rather than JSX's more sensible curly brackets I'm still waiting for the 2019 equivalent of http://haml.info/

I think Pug is the closest thing to Haml with traction: https://pugjs.org/language/conditionals.html Here's a Pug -> JSX transformation: https://github.com/pugjs/babel-plugin-transform-react-pug Detouring from the most popular path tends to come at the price of tooling idiosyncrasies that are rarely worth it, but it seems to at least work with eslint-react and has syntax highlighting in some editors.

Love it! Thanks for sharing

Re: How we do Vue: one year later (2017)

#146

I wrote this article back in 2017. A lot has changed since then. If anyone has any questions I'd be happy to answer them. We now use Vue in our data science startup meltano.com.

What would you change about or add to the article now?

That's a great question. I'll have to write another article to answer it.

Re: How we do Vue: one year later (2017)

#147

I wrote this article back in 2017. A lot has changed since then. If anyone has any questions I'd be happy to answer them. We now use Vue in our data science startup meltano.com.

What role does Haml still play for you, if any?

I've moved to the Meltano team at GitLab and we don't use haml at all. Just plain old HTML.

Re: How we do Vue: one year later (2017)

#148
post #16

I wrote this article back in 2017. A lot has changed since then. If anyone has any questions I'd be happy to answer them. We now use Vue in our data science startup meltano.com.

what are worst parts of vue for you?

I can't think of any bad parts of Vue off the top of my head. I really do enjoy the whole library. Although I think slots is a harder concept for most to grasp then it needs to be.

Re: How we do Vue: one year later (2017)

#149
post #22

I love Vue and use it wherever I can. I used to feel iffy about the angular-y syntax and how CSS JS and HTML all often live in the same file, but I've come to love the way that coupling embraces the component architecture: "This file has one (1) self-contained component that does this one thing". That plus the built-in routing, global state management, and scoped CSS/SCSS made me never want to go back to React. The o…

> I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done"

I had a similar experience. I will say, though, that the nativescript-vue plugin is now officially supported by Telerik rather than just a community plugin, so it should theoretically be getting easier to use.

Re: How we do Vue: one year later (2017)

#150
post #133

Earlier quoted context omitted.

Compared to React (and React’s JSX) Vue’s syntax is orders of magnitude more complex and is very inconsistent: https://news.ycombinator.com/item?id=19199423

I feel that this baybe the case when you know js very well and it's just easier for you to write 'custom-js' that will be transpiled to regular one. I'm working on backend most of the time and relatively recently I needed to do switch to frontend part of our service. For me Vue seems much easier and less confusing. You just have your plain html template and a few 'hooks' to make it work with your js script. >magnitud…

I think this is accurate. My background is also in the backend realm and so I'm not a frontend person and my Javascript knowledge is marginal. I recently had to take on a more frontend project and I went with Nuxt/Vue over React.

That being said, I do share some of the other comments about how it can be confusing with bound elements and iterating over objects, or areas you aren't allowed to use string concatenation. A lot of this magic happens behind the scenes so it's a bit of trial and error, and feels foreign if you're used to being able to do those sorts of things in the past.

I also think that React (with JSX) is a bit more "out in the open" about how things work and what is expected, without reading tons of documentation, and less under-the-hood magic. So it's easier to get up to speed, and your JS knowledge will improve over time (especially if you already know other languages).

Post reply on HN