Earlier quoted context omitted.
Isn't elm a language? Why compare it with frameworks?
People compare Rails to python/PHP often enough.
I heard people comparing rails to django, never to pure python though.
Our long term plan to make GitLab as fast as possible with Vue and Webpack
91–100 of 304 posts
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#92Can someone explain why someone would choose Vue over React (or one of the clones)? When I looked at the docs for Vue it reminded me of my Backbone days.
If you already know react and are happy using it, then there's no reason to use Vue. But if (like me) you were never quite able to figure out how to use React (especially all the build tooling that's suggested in every tutorial), then Vue is worth a look as it's incredibly simple to get started with and easier to learn. I find it especially appeals to people coming from a place of familiarity with html and css (where…
I had the same problem, couldn't figure out how to use React, I started learning VueJS and in a week I had built a fully working app, https://github.com/thewhitetulip/Tasks-vue
I started to write this tutorial, an example based guide, https://github.com/thewhitetulip/intro-to-vuejs
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#93Sadly I think the problem of GitLab's sloweness is not the UI framework :(
We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#94Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.
Totally agree, maybe they would need UI polishing to make it more user-friendly a la "GitHub". But first priority definitely should be backend speed improvements, not frontend.
Also good backup strategy. :)
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#95It's good to see vue.js getting some love. I believe it would be the preferred Web framework these days if it had backing from FB like React does. Too many people fall into the trap of believing a tech is the best just because some big Corp sponsors it. I fell for Angular once for the same reason.
Disagree. React was released in 2013, but use didn't take off until Dan Abramov released his Flux implementation, Redux, in early 2015[0]. That is a full two years of a Javascript view library with the backing of Facebook where it didn't leave much of a mark vs angular.
Most of the projects that contributed to React/Redux becoming popular[1] were developed outside of Facebook - altho some of those developers went on to work for Facebook.
I'd also argue that it isn't the projects themselves that made it popular, but rather the design philosophy that React/Redux brings to a project that is popular. The Redux part is a Flux implementation, but the React part could also be seen as a "React" implementation - one that certainly has flaws and could probably be improved on much in the same way Flux has been improved on (there are other parts that could use this as well).
If you think of the React/Redux style as opposed to React/Redux the code projects i'd characterize it as an ad-hoc, componentized, purely functional and immutable architecture. But that is just listing characteristics, rather than capturing what it is about. Formalizing what it looks like could bring improvements to the ecosystem.
I'd also argue that big company backing has little meaning in web application development, unlike enterprise services, hardware and operating systems. I have two enterprise clients who both migrated from jQuery style web applications to Angular 1 largely on the basis of Google's support. They're now both migrating to React/Redux and have been burnt by Google's support - meaning two periods of developer re-training, prototypes, testing and then migrating code in just over a single year. There are similar situations with Microsoft's ASP.NET MVC although they're handling the transition much better.
[0] iirc he released it earlier, but first half of 2015 is when React + Redux "hockey stick'd"
[1] the term is definitely React/Redux - React isn't (and wasn't) as successful on it's own. Welcome to the new GNU/Linux.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#96> For example, the profile page could be potentially very light, and there would be no reason for that if someone is linked directly to the profile page; it should load every single piece of Javascript in our project. There are plenty of ways to do that with single Page apps; it's not a great argument against all single page apps, just poorly designed ones.
Open question: how well does Vue handle isomorphism? Our standard React template now for new projects is isomorphic, and we're porting old projects when/where we can.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#97Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.
Yeah, being unable to host Gitlab under 512MB is just too bloaty for me. I know Gogs doesn't have this issue for the same features I use. I still use Gitlab though because it's the mainstream.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#98It's good to see vue.js getting some love. I believe it would be the preferred Web framework these days if it had backing from FB like React does. Too many people fall into the trap of believing a tech is the best just because some big Corp sponsors it. I fell for Angular once for the same reason.
This isn't a phenomena limited to JS frameworks either. These days, anything corporate-sponsored tends to overtake alternatives (Rust vs Crystal, etc)
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#99> For example, the profile page could be potentially very light, and there would be no reason for that if someone is linked directly to the profile page; it should load every single piece of Javascript in our project. There are plenty of ways to do that with single Page apps; it's not a great argument against all single page apps, just poorly designed ones.
An SPA has to be an "all in" thing though. If visiting the profile page then going back to the rest of the app is a possibility then the page load time is too high. SPA load times are only accepted because they are a one time cost.
That's not correct. A well-written SPA can lazy load components, take advantage of code splitting, load in modules asynchronously after the initial load. There are plenty of strategies to push the time-to-interactive timing right down. Webpack 2 supports multipage apps with individual dependency graphs for each page. SPAs have progressed considerably over the past few years.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#100I really think for most cases you only need a view library instead of a heavy application framework. There are only a few cases there something as heavy as Angular or Ember is justified and in many scenarios a thinner view layer like Vue, React, Inferno etc is much better suited. Most of the web is simple enough to not need fancy http features or complex routing support. Everyone rushed to Angular without considering…
> I really think for most cases you only need a view library instead of a heavy application framework.
You may not even need that if you target modern browsers. You can componentize your code using Web Components (or Polymer) and optionally drop in a data management library such as Redux or MobX, and that's that. If your application mostly consists of plain HTML pages enhanced by some JavaScript widgets here and there, that's more than enough.
That said, I don't think GitLab falls in this category of applications, and I honestly feel going the full-blown SPA route with server-side rendering will work better for them.