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

Our long term plan to make GitLab as fast as possible with Vue and Webpack

about.gitlab.com

Post reply on HN
Print view View original

181–190 of 304 posts

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#181

Post by justinlaster »

duncanawoods wrote: post #131
scrollaway wrote: post #124

Earlier quoted context omitted.

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at). JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

> will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle br…

I will never understand why people think JSX style processing is a good idea. It's hiding what's actually happening, at no benefit (or very little benefit). At least with the former (C#) I can neatly build things up, reuse those components, instead of passing some monstrosity around.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#182

Post by tashoecraft »

jamra wrote: post #73
elliotlarson wrote: post #65

Earlier quoted context omitted.

I agree with this. If you're augmenting a traditional request/html-response web app with some JavaScript functionality, a lighter weight view library fits the bill nicely. But, if you're developing a SPA that consumes an API, you might really enjoy what a more holistic framework provides in terms of code structure, front-end data management, and just general guidance on how to do certain standard things, like basic C…

Jumping on the bandwagon here... The key is the single directional data flow. It was purposed in Flux, made better in Redux, and is used in Angular as well. If you're writing a large web app, the dependency injection part of Angular 2+ isolates your modules much better than Redux. You won't need a single file with action creators. Each service can contain its own information. Though not a feature of Angular, Observab…

Also jumping in.

The biggest problems with Angular2+ is that they called it Angular, and had a terrible release.

It's not Angular, it's a completely different framework. They rode their own hype train and it's made searching for tutorials, examples, libraries much more difficult.

I was lucky in that we didn't start our project until after the true release happened, but having such a long alpha, beta, and release candidate stage really hurt momentum. Articles and tutorials written before June 16' can be completely useless with the amount of breaking changes.

With that all said I'm really liking Angular 2+ with ngrx (redux). The problems only really appear when I'm trying to bring in other libraries as they haven't been written well.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#183

Post by Longwelwind »

phasecode wrote: post #72
jbhatab wrote: post #66

Earlier quoted context omitted.

disagree. React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale. I think vue is a perfect fit for gitlab but not quite perfect for facebook or a more complex web app on the front end.

Are there any specific reasons you can point to, rather then a blanket statement?

React managed to make HTML "statically typed".

If I make a typo in the name of a component or the name of an attribute used in a HTML tag property, Typescript will catch it. Since Vue & Angular uses template strings, TS can't do the same check.

This makes catching errors and refactoring easier.

I used to prefer Vue, but since I've discovered Mobx, I only use React now. It took me a lot of time to properly learn the tools, but I'm pretty happy with them now.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#184

Post by vog »

duncanawoods wrote: post #131
scrollaway wrote: post #124

Earlier quoted context omitted.

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at). JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

> will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle br…

> That single line was more of an HN comment format limitation.

What limitation are you talking about?

    var element = DOM.p(
        {id : "thing"},
        DOM.div(),
        DOM.div()
    );

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#185

Post by sb8244 »

justinlaster wrote: post #181
duncanawoods wrote: post #131

Earlier quoted context omitted.

> will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle br…

I will never understand why people think JSX style processing is a good idea. It's hiding what's actually happening, at no benefit (or very little benefit). At least with the former (C#) I can neatly build things up, reuse those components, instead of passing some monstrosity around.

I don't understand this. You could build up the template using jsx exactly like you could otherwise. For instance, I could put that in a variable and then use it in another template via {}

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#186

Post by dragonwriter »

ythn wrote: post #177
jetter wrote: post #154

Vue.js is just a better option for every-day development in smaller and mid-sized teams, it gives more freedom working with arbitrary html, which is huge, it also gives easy start - you don't need compiler to use Vue across your legacy codebase. React is a good thing if you are a hard-core fulltime frontend dev in a big team, I guess. That's why potential of Vue.js popularity is ~25-30% of jQuery worldwide usage whil…

I'm assuming in the web dev world "legacy codebase" is used very loosely here. In my company, "legacy codebase" is referring to C code from the 70s that is still ticking today.

"Legacy codebase" generally refers to anything that doesn't an meet an organization's current standards for new development, especially to the extent that that limits maintenance efforts.

That standards may move faster in web dev doesn't make the use of the term any looser there.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#187

Post by justinlaster »

sb8244 wrote: post #185
justinlaster wrote: post #181

Earlier quoted context omitted.

I will never understand why people think JSX style processing is a good idea. It's hiding what's actually happening, at no benefit (or very little benefit). At least with the former (C#) I can neatly build things up, reuse those components, instead of passing some monstrosity around.

I don't understand this. You could build up the template using jsx exactly like you could otherwise. For instance, I could put that in a variable and then use it in another template via {}

You could, but it's unintuitive (in my opinion) to do so -- which was the parent's comment larger point. You're not doing anything different, and to an extent the latter is actually lying about what's going on (you're not writing HTML). I also lose a certain level of tooling by doing it the JSX way. Why try to mask what you're doing? Why make it harder for your tools to help you out?

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#189

Post by treehau5 »

duncanawoods wrote: post #116
fleshweasel wrote: post #88

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week. I also am strongly against string…

JSX frustrates me. When did we suddenly start thinking syntax was desirable again? When did the complexity of combining markup syntax and a programming language become a good idea? Why are we forcing this crazy complexity into every language and every IDE / code editor out there? I much prefer react with standard functions e.g. var element = DOM.p({id : "thing"}, DOM.div(), DOM.div()); You can use an API like this in…

> When did the complexity of combining markup syntax and a programming language become a good idea?

When unobtrusive javascript became a thing.

> As an industry, we’ve already decided: HTML and JavaScript belong together.

https://medium.com/@housecor/react-s-jsx-the-other-side-of-t...

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#190

Post by rk06 »

fleshweasel wrote: post #88

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week. I also am strongly against string…

You do know that Vue support jsx. Just not react's jsx.
Post reply on HN