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

How we do Vue at GitLab: one year later

about.gitlab.com

Post reply on HN
Print view View original

181–190 of 208 posts

Re: How we do Vue at GitLab: one year later

#181

Post by allover »

ZenoArrow wrote: post #164
allover wrote: post #92

Earlier quoted context omitted.

I don't mean to be an arse, but if you agree with my point, then maybe you can see why I disagree that your "that and" is a valid strike against React/in favour of Vue.

Simplicity makes picking up the unfamiliar easier. You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.

> Simplicity makes picking up the unfamiliar easier.

The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve.

> You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.

True, I was really just suggesting questioning instincts when evaluating tools based on the initial 'time to get started'.

Re: How we do Vue at GitLab: one year later

#182

Post by hmillison »

Etheryte wrote: post #174
jrochkind1 wrote: post #154

This is one of the most aggressive, defensive, and religious comments thread list I've ever seen in a highly rated HN post. Not sure what to take from that.

Javascript libraries and their preferences are always a high tension discussion because at the end of the day, it often comes down to whether you made the right decision for years to come.

Totally agreed. Unfortunately (and fortunately, depending on how you look at it), there is no single benevolent dictator of JS to help you make your decision like in other communities.

I think this quote from this article is a good summary of this discussion: "Scala people don't have time for redditing and blogging, they're busy getting crap done."

While it might seem like all the JS devs are arguing on here over their choices, there are many folks who are silently being incredibly productive with whatever tool they choose.

Re: How we do Vue at GitLab: one year later

#183

Post by swsieber »

neals wrote: post #170

I wanted to build something in Vue a few months ago. I really like the single-file-component thing. I also like the code to update automatically and my browser to refresh. I decided on Webpack. First time using it and no idea where to get started. I ended up downloading some boilerplate webpack / vue / vueX that now does everything for me, but I have no idea what webpack is actually doing or how it is doing that. I'm…

I found this link to be an enlightening tutorial on webpack:

https://what-problem-does-it-solve.com/webpack/intro.html

Re: How we do Vue at GitLab: one year later

#184

Post by mort96 »

ZenoArrow wrote: post #166

I hope one day more web developers will realise all the major JS frameworks are just a band aid to plug the gaps in vanilla JS. It should be easy to build web apps using vanilla JS. No frameworks pushing a certain way of working, just a reliable batteries-included language that you're free to extend with your own application-specific extensions and mix-and-match external libraries, just like desktop app developers ha…

Say that your opinion is correct, and every web developer agrees with it. What could web developers do about it? The gaps you are talking about in vanilla JS does exist, so until they're plugged, web devs would still prefer to use these frameworks until the standard bodies and browser vendors make a better alternative.

Web Components might be the solution, but it's not exactly ready yet: https://caniuse.com/#search=components

Re: How we do Vue at GitLab: one year later

#185

Post by ZenoArrow »

allover wrote: post #181
ZenoArrow wrote: post #164

Earlier quoted context omitted.

Simplicity makes picking up the unfamiliar easier. You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.

> Simplicity makes picking up the unfamiliar easier. The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve. > You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries. True, I was really just suggesting questioning instincts when evaluating tools…

> "The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve."

I'm aware of Rich Hickey and Clojure. In my experience with Lisps, although they are superficially simple, they make you do more abstraction work than is necessary in more commonly used high-level imperative languages. Lisp seems to strongly encourage building a high number of helper functions, which is fine if you're highly opinionated about how a job should be done, and less so if you just want to import some battle-tested libraries and write something that gets the job done. I suspect this is where the learning curve with Clojure really comes in, in that it's more closely related to being learn how to architect an application in a Lisp-friendly way than it is about getting familiar with the language.

Re: How we do Vue at GitLab: one year later

#186

Post by ZenoArrow »

mort96 wrote: post #184
ZenoArrow wrote: post #166

I hope one day more web developers will realise all the major JS frameworks are just a band aid to plug the gaps in vanilla JS. It should be easy to build web apps using vanilla JS. No frameworks pushing a certain way of working, just a reliable batteries-included language that you're free to extend with your own application-specific extensions and mix-and-match external libraries, just like desktop app developers ha…

Say that your opinion is correct, and every web developer agrees with it. What could web developers do about it? The gaps you are talking about in vanilla JS does exist, so until they're plugged, web devs would still prefer to use these frameworks until the standard bodies and browser vendors make a better alternative. Web Components might be the solution, but it's not exactly ready yet: https://caniuse.com/#search=c…

Web Components are a good step forward.

To understand how to improve JS, try writing in vanilla JS (no frameworks) and find the common pain points. Organise with fellow JS developers to get features to address these shortcomings in the EcmaScript standard. Once this is done, use tools like Babel to polyfill the missing functionality from the EcmaScript standards until browser vendors implement them. Rinse, repeat.

Re: How we do Vue at GitLab: one year later

#187

Post by shados »

knowThySelfx wrote: post #134
shados wrote: post #110

Earlier quoted context omitted.

If you remove styled-component specific tooling from the equation to simplify the argument and just use Glamorous instead of styled-components (which are very close to the same thing except the later is just JS), then it's exactly because of tooling. The reality is that tooling for templates (even Angular or Mustache style) is pretty terrible. Tooling for CSS is just as terrible. Static analysis or doing simple thing…

Is it bad to write without all these JS tools? We just use Visual Studio and include the standalone Vue.js file. We write plain css (no sass etc) and js with some occasional JQuery. We don't use Nodejs and its build tools (Kinda don't like the complexity all those tools bring. You are more worried about the tooling than the actual problem at hand). We use Ajaxmin and Httpcombiner. That's it for Frontend. Vuejs is gre…

It's not bad at all. You just have different requirements. I prefer React, but if the apps I was working on came to change in requirements, I'd be very happy to have Vue as an option. I don't think having 16 different major frameworks that overlap in functionality is healthy, but having a handful of fairly distinct ones that overlap on some points is just a good thing.

We have hundreds of full sized frontend applications, millions of lines of both javascript and scss. Thousands of extremely complex i/o operations and algorithms. We push the tools in the ecosystem to their limit and have to write our owns where they fail us.

And when I'm at home making a small app, create-react-app and VSCode, then npm install-ing styled-components, is all I need to replicate 80% of the above. It's all just JavaScript so all my tools just work the way I expect them to.

Not everyone needs (or want!) this. And that's okay.

Re: How we do Vue at GitLab: one year later

#188

Post by kabes »

Although they are very different under the hood, as a developer the experience vue gives is very much like component based angularjs (version 1). Yet everyone seems to hate angular 1, while they love vue. I really can't see why.

Re: How we do Vue at GitLab: one year later

#189

Post by always_good »

Etheryte wrote: post #174
jrochkind1 wrote: post #154

This is one of the most aggressive, defensive, and religious comments thread list I've ever seen in a highly rated HN post. Not sure what to take from that.

Javascript libraries and their preferences are always a high tension discussion because at the end of the day, it often comes down to whether you made the right decision for years to come.

This explains a lot of fanboism in general. Like when I would argue about how Xbox > PS3 on forums as a kid because my parents certainly weren't going to buy me both.

I was stuck with the Xbox so I had to validate that reality to myself by defending it on the internet.

It's no different on HN.

Re: How we do Vue at GitLab: one year later

#190

Post by always_good »

saas_co_de wrote: post #173
nikcub wrote: post #147

Earlier quoted context omitted.

Whats with the insults? I can get preferring one platform over another, but insulting people is just lame. The React and Redux developers are incredibly good at what they do - they've also spent a lot of time putting out material, books, video courses, blog posts, talks help everybody else understand the new paradigm they've created They can't be that stupid when a lot of modern javascript framework components are ei…

> They can't be that stupid when a lot of modern javascript framework components are either direct clones of, or influenced by, their work The JS ecosystem is like the baskin robbins of s t. Which is mind-blowing because JS has gotten so much better and browsers have gotten so much better in the past 10 years. Yet the apps people are creating today are worse that the s t people were creating with IE8 and jQuery. I am…

Pointing out that people can make crap isn't an argument that supports your assertion that the developers of a tool are stupid.

Can you list off any tools that you like where there aren't any people using them to make crap? Does the fact that some people produce junk undermine your success using a tool? Or is it actually inevitable that people will use a tool to produce garbage?

So I'm not understanding your point.

Post reply on HN