22 ms·

I 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 Angu

I 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 if they needed such a heavy library. How Angular even runs on mobile is anyone's guess.

developer2 10y ago
Unfortunately for GitLab, they've locked themselves into a position of trying to compete directly with GitHub. If GitHub has instantly smooth transitions between page loads while browsing a repository, then GitLab is going to follow suit. It's really hard to be competitive while ignoring the nagging thought that "competing requires copying the competitor".
- comex 10y ago
  Performance matters - a lot. It's often overlooked because its effect on users is more unconscious than consciously noticed, but even small speedups greatly affect user motivation, as measured by any number of blog posts about "page load time" and "conversions". However, "instantly smooth transitions" may not require using JavaScript. According to the blog post, GitLab observed a performance increase after ditching Turbolinks[1]. Indeed, sites that use JS to speed up page loads are often compensating for what would otherwise be an excessively slow load, due to having lots of scripts or whatnot. And that's only a partial fix: the user still experiences that slow load whenever they come in from an external site or open links in a new tab/window. If you can make "real" page loads fast, you avoid that problem. [1] ...though it doesn't seem to have been measured very scientifically - to quote from the pull request: "I thought I noticed that pageloads were a lot more snappy, and one other reviewer said the same. Not the most rigorous way to test performance, but it helps."
  - irq11 10y ago
    The irony, of course, is that GitHub doesn't use any of the JS framework complexity that people here seem to think is necessary. They use jQuery and PJax. Sometimes I feel like 95% of the thrashing in the JS world is from people trying to fix the wounds inflicted by the previous Hot New Thing...
    - Touche 10y ago
      Yeah, exactly. It's amazing that so many developers use GitHub, which has excellent performance, but don't take any of its lessons with them.
- jobvandervoort 10y ago
  Performance is really important, especially to user experience. We want GitLab to be fast, independent of the scale it's used at. Right now, GitLab is fast and snappy for people that self-host it, but GitLab.com is not and we're not happy with that [0]. Making our front end performant is part of that and I'm happy our engineers have been working hard on that. We have been using Prometheus extensively to monitor speed of transactions on the backend and I'm seeing a strong push to more monitoring to front end monitoring as well (I owe you a link here). [0]: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59
  - sytse 10y ago
    The issue you linked to was moved to https://gitlab.com/gitlab-com/infrastructure/issues/947 https://gitlab.com/gitlab-com/infrastructure/issues/947 The performance issues we plan to work on are in https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&author_username=pcarranza&label_name[]=performance https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
jeswin 10y ago
IMO this is not true at all. Any non-trivial SPA not based on a framework will end up inventing one eventually that solves the very same problems which were already solved for you. Examples being history management and back button, state management (especially if you prefer immutability), and server side rendering. On the other hand, if the app is not an SPA, you probably don't need the framework. Both history and state gets managed on the server to an extent. However, most apps are better as SPAs rather than these hybrids. Informational websites being the exception.
- andrei_says_ 10y ago
  Maybe by Vue they mean Vue + vuex + Vue router.
- elliotlarson 10y ago
  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 CRUD.
  - jamra 10y ago
    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, Observables are the baked in method of HTTP. Using Observables are far superior to Promises. You can compose Observables and make the callback part of javascript a lot easier on you. You can also cancel Observables, which is not possible with promises. One of the things I miss with React is JSX, however, it's not so bad. There is even a mobile framework called nativescript that allows you to write Angular 2+ code with Native UI. People jumping on the Angular hate train are mostly riding the vapor from Angular 1.X. The new framework has been done very well.
jayajay 10y ago
I've always been a pretty average front-end guy, but React actually makes me like writing front end code. It's just a great way to think.
- philliphaydon 10y ago
  I hate writing react. I have much more enjoyable experience with vue or riot.
  - jayajay 10y ago
    > I hate writing react. Out of curiosity, what was the straw that broke the camel's back?
    - philliphaydon 10y ago
      After a few hours of Vue / Riot I could sit and begin writing a full fledged app. React for me was a bigger barrier to entry, i kept running into road blocks and searching google how to do things then everything is like "you need flux" or all these other things and I just got more confused and frustrated. Once you know it, its great, powerful, fast, a pleasure to use. But I still prefer vue/riot. Simple easy straightforward.
      - jayajay 10y ago
        Thanks for sharing. Enough people are hopping onto the React → Vue train for it to be worth looking into.
      - spion 10y ago
        Yeah, the main problem with React is that you actually want React+MobX, not React+Flux :)
GeneralMaximus 10y ago
> 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.
Shorel 10y ago
All I ever used of Angular was the parts that Vue kept. So, it was the right idea, and the Angular creators just got carried away.
deleted 10y ago
[deleted]

developer2 10y ago

Unfortunately for GitLab, they've locked themselves into a position of trying to compete directly with GitHub. If GitHub has instantly smooth transitions between page loads while browsing a repository, then GitLab is going to follow suit. It's really hard to be competitive while ignoring the nagging thought that "competing requires copying the competitor".

comex 10y ago
Performance matters - a lot. It's often overlooked because its effect on users is more unconscious than consciously noticed, but even small speedups greatly affect user motivation, as measured by any number of blog posts about "page load time" and "conversions". However, "instantly smooth transitions" may not require using JavaScript. According to the blog post, GitLab observed a performance increase after ditching Turbolinks[1]. Indeed, sites that use JS to speed up page loads are often compensating for what would otherwise be an excessively slow load, due to having lots of scripts or whatnot. And that's only a partial fix: the user still experiences that slow load whenever they come in from an external site or open links in a new tab/window. If you can make "real" page loads fast, you avoid that problem. [1] ...though it doesn't seem to have been measured very scientifically - to quote from the pull request: "I thought I noticed that pageloads were a lot more snappy, and one other reviewer said the same. Not the most rigorous way to test performance, but it helps."
- irq11 10y ago
  The irony, of course, is that GitHub doesn't use any of the JS framework complexity that people here seem to think is necessary. They use jQuery and PJax. Sometimes I feel like 95% of the thrashing in the JS world is from people trying to fix the wounds inflicted by the previous Hot New Thing...
  - Touche 10y ago
    Yeah, exactly. It's amazing that so many developers use GitHub, which has excellent performance, but don't take any of its lessons with them.
jobvandervoort 10y ago
Performance is really important, especially to user experience. We want GitLab to be fast, independent of the scale it's used at. Right now, GitLab is fast and snappy for people that self-host it, but GitLab.com is not and we're not happy with that [0]. Making our front end performant is part of that and I'm happy our engineers have been working hard on that. We have been using Prometheus extensively to monitor speed of transactions on the backend and I'm seeing a strong push to more monitoring to front end monitoring as well (I owe you a link here). [0]: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59
- sytse 10y ago
  The issue you linked to was moved to https://gitlab.com/gitlab-com/infrastructure/issues/947 https://gitlab.com/gitlab-com/infrastructure/issues/947 The performance issues we plan to work on are in https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&author_username=pcarranza&label_name[]=performance https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

jeswin 10y ago

IMO this is not true at all. Any non-trivial SPA not based on a framework will end up inventing one eventually that solves the very same problems which were already solved for you. Examples being history management and back button, state management (especially if you prefer immutability), and server side rendering. On the other hand, if the app is not an SPA, you probably don't need the framework. Both history and state gets managed on the server to an extent. However, most apps are better as SPAs rather than these hybrids. Informational websites being the exception.

andrei_says_ 10y ago
Maybe by Vue they mean Vue + vuex + Vue router.
elliotlarson 10y ago
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 CRUD.
- jamra 10y ago
  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, Observables are the baked in method of HTTP. Using Observables are far superior to Promises. You can compose Observables and make the callback part of javascript a lot easier on you. You can also cancel Observables, which is not possible with promises. One of the things I miss with React is JSX, however, it's not so bad. There is even a mobile framework called nativescript that allows you to write Angular 2+ code with Native UI. People jumping on the Angular hate train are mostly riding the vapor from Angular 1.X. The new framework has been done very well.

jayajay 10y ago

I've always been a pretty average front-end guy, but React actually makes me like writing front end code. It's just a great way to think.

philliphaydon 10y ago
I hate writing react. I have much more enjoyable experience with vue or riot.
- jayajay 10y ago
  > I hate writing react. Out of curiosity, what was the straw that broke the camel's back?
  - philliphaydon 10y ago
    After a few hours of Vue / Riot I could sit and begin writing a full fledged app. React for me was a bigger barrier to entry, i kept running into road blocks and searching google how to do things then everything is like "you need flux" or all these other things and I just got more confused and frustrated. Once you know it, its great, powerful, fast, a pleasure to use. But I still prefer vue/riot. Simple easy straightforward.
    - jayajay 10y ago
      Thanks for sharing. Enough people are hopping onto the React → Vue train for it to be worth looking into.
    - spion 10y ago
      Yeah, the main problem with React is that you actually want React+MobX, not React+Flux :)

GeneralMaximus 10y ago

> 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.

Shorel 10y ago

All I ever used of Angular was the parts that Vue kept. So, it was the right idea, and the Angular creators just got carried away.

deleted 10y ago

[deleted]