
Our long term plan to make GitLab as fast as possible with Vue and Webpack - miqkt
https://about.gitlab.com/2017/02/06/vue-big-plan/
======
fleshweasel
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 references to model properties in your
template. Again, it's much better to use tools that provide some static
validation of what you're doing.

Give me React with TypeScript to help me make sure I'm passing around what I
said I'm expecting to receive at each point as features are changed and added,
and I'll be in business.

Honestly, I use React in spite of my opinion of Facebook.

~~~
duncanawoods
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 every language without any hacks. It doesn't
hurt readability or productivity and it has normal expression evaluation
semantics. JSX isn't syntactic sugar, its a gross "syntactic artificial
flavour" because it doesn't make the syntax easier, it just makes it look
something a bit like HTML but with dozens of subtle differences e.g. attribute
names, attributes values, tag closing rules, special extensions etc.

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

~~~
duncanawoods
> 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](http://imgur.com/a/nVWdC)

JSX

[http://imgur.com/a/qwAfD](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 brackets, end tags and escaping expressions with
{}, it can actually be more verbose.

~~~
hacker_9
I'm a C# guy and even I would say the JSX is far more readable there. I'm sure
there's a law somewhere that says the less abstraction the better, that can be
applied in this case.

~~~
duncanawoods
I don't mind if people prefer JSX its just a shocking cost - rewriting
language ASTs, build tools and IDEs for something that rhymes with html but is
really only a couple of characters away from standard language constructs.

> I'm sure there's a law somewhere that says the less abstraction the better,
> that can be applied in this case

JSX is literally an extra level of abstraction. You are not writing html but
calling a function to create a data structure element and JSX totally
obfuscates that. I pity poor programming newbies trying to understand what JSX
is actually doing "so you are telling me <div> is a function...but?".

In the functional form its just your normal language, nothing is disguised,
everyone can see what it is doing and no post-processing magic is required
e.g.

    
    
        public class DOM
        {
            public static IElement div(object attributes, params IElement[] children) 
            {
                return new Element(...);
            }
        }

~~~
spion
I agree with everything you say, except the "shocking cost" part. Its all a
matter of perspective.

You would have to write the transpiler anyway, since on a larger team if
you're working with a designer, you would probably get HTML from them and soon
get tired of manually translating it to function calls.

I'd bet this is how JSX got started in the first place.

------
iamleppert
You want to make your site fast?

Generate the markup on the server and send it down to the client! It's post-
modern web development. Back to black.

You don't need 100 KB of code to spit down a table of data or show someone a
directory listing of their github project. You don't even need an SPA, bunny.

And for goodness sake, when you do need to do anything in javascript, you can
use document.createElement and document.createDocumentFragment. These are
perfect 1:1 browser APIs that allow you to do everything you've ever wanted,
there's no magic, they call directly into the browser engine to give you what
you need.

If you want to increase performance, start first by measuring everything. Time
to first byte. Time to DOMContentLoaded. The page onload event.
window.performance timings; do real user monitoring, not TODO app benchmarks
on the latest framework flavor of the week.

The entire web community needs a healthy dose of pragmatism. But it's okay, it
gives me extra work. I really enjoy doing freelance performance work and
telling everyone which code/library/framework is to blame for performance
issues and rewriting everything so simply. Show people what works and you'll
find they shut up real quick.

~~~
randomsofr
> Generate the markup on the server and send it down to the client!

You are so smart, how come no one thought about that before.

~~~
hrayr
Obviously they did, hence the "It's post-modern web development." No need for
snark.

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

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

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

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

~~~
andrewstuart2
> They rode their own hype train

This is my single biggest problem with Angular 2. It's not Angular, but in
calling it "Angular 2," they effectively killed off a powerful framework which
had a promising future, all while basically hamstringing Angular 2 from the
start for (at least) the reasons you mentioned.

~~~
spion
Its actually worse now, since they decided to call all versions of angular
"just Angular".

I'm not sure what the reasoning is behind this.

------
OJFord
I'd only heard of Vue as a name before this, but I followed the link to the
documentation, which looks fantastic:

    
    
        <div id="app">
          {{ message }}
        </div>
    
        var app = new Vue({
          el: '#app',
          data: {
            message: 'Hello Vue!'
          }
        })
    

> Hello Vue!

> _This looks pretty similar to just rendering a string template, but Vue has
> done a lot of work under the hood. The data and the DOM are now linked, and
> everything is now reactive. How do we know? Just open your browser’s
> JavaScript console (right now, on this page) and set app.message to a
> different value._

I guess that didn't take any extra work to setup, since it's a fair assumption
the Vue docs are rendered with Vue (!) - but a really easy yet nicely
motivating introduction.

Obviously this isn't _too_ tricky with 'vanilla' JS, but there's certainly
more ceremony involved, and I'm sure the templates can be more complex such
that the JS/Vue contrast would be much greater.

~~~
mgkimsal
vue feels to me like a condensed knockout. i still use knockout on some
projects, but have used vue on a couple new ones too. as much as I'd like to
see knockout progress - simplify a bit more to be more compact like vue, i'll
take vue if that never happens.

anyone using knockout looking to migrate, vue is a worthy spiritual successor
imo.

~~~
skrebbel
Do you end up using View Models in Vue just like you might in Knockout? To me,
a big benefit of React is making that translation step implicit; I like the
_idea_ of View Models but in practice I'm just schlepping a lot of data around
between the models and view models.

~~~
mgkimsal
It _feels_ like I'm using view models, but I don't think I am. The idea of a
'vue object' ties some metadata, data and methods together, which seems like a
somewhat tighter coupling, but also a bit more pragmatic (less "schlepping").

I'm no expert in either, but one of the things I liked about knockout early on
was that it was pretty straightforward to decorate existing pages with
knockout functionality, and vue has been the same way. Technically react may
be the same way, but it never felt as easy as vue or ko. (I've only recently
done some 'hello world' stuff in react, so again, no expert) I do have
production code with knockout in multiple project spanning back about 4 years
or so, so that's where my current comfort-zone is, but vue is starting to
replace that.

[https://vuejs.org/v2/guide/comparison.html#Knockout](https://vuejs.org/v2/guide/comparison.html#Knockout)
has a very short comparison, but they link to a "todo list" gist here
comparing the two sets of code:
[https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8...](https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8f6dccb89)

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

~~~
realharo
I recently needed a simple self-hosted git web interface for about 3 people,
and I only have a cheap 2GB RAM VPS that also runs other things. After looking
at gitlab's requirements, I didn't even try.

Setting up the gitea docker container was so easy ([https://docs.gitea.io/en-
us/install-with-docker/](https://docs.gitea.io/en-us/install-with-docker/))
and it only takes like 160 MB of RAM plus it's super fast.

Then again, I only needed the more basic features, so I doubt that's gitlab's
target audience anyway.

~~~
zebra9978
There's also gitbucket built in scala. The UI is much nicer than gitea.

[https://gitbucket.github.io/gitbucket-
news/gitbucket/2017/01...](https://gitbucket.github.io/gitbucket-
news/gitbucket/2017/01/29/gitbucket-4.9.html)

running it is simply _java -jar gitbucket.war_

~~~
realharo
I don't know, that UI looks a little too "mobile first" to me (for something I
would only use on my computer).

EDIT: also, the colors seem quite dull from those screenshots

~~~
sandGorgon
heh heh.. no real way to win. [https://gitlab.com/gitlab-org/gitlab-
ce/issues/6057](https://gitlab.com/gitlab-org/gitlab-ce/issues/6057)

~~~
realharo
Nothing wrong with responsive UI, just don't create something meant for phones
and then just scale it up to a larger screen. Which is what bootstrap,
material design etc. often end up looking like.

------
jetter
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 while React will probably might get 5-10%
at most - that's just my impression after using both React and Vue.
[http://pixeljets.com/blog/why-we-chose-vuejs-over-
react](http://pixeljets.com/blog/why-we-chose-vuejs-over-react)

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

~~~
Touche
That's right, in the web dev world "legacy codebase" is 3 or 4 years old,
created by a previous team who all quit once they finished the rewrite of the
previous "legacy codebase".

~~~
ams6110
3 or 4 years? Seems generous. Lately it seems anything more than a year old is
"legacy" or "technical debt" because the team is now using other frameworks or
libraries.

------
rkwasny
Something went terribly wrong in our field ....

"On GitLab, our pages would load an average of 20kb on each page load versus
the full JavaScript file size of 800kb+."

What exatly takes 800kb? I don't see a 3d animation/game on every gitlab
page...

IMHO the solution to all this craziness is just generate small mostly-static
page quickly and do not have 200 onLoad() functions.

~~~
jakecodes
Our entire JS is 800kb not each page. So we are splitting it on a per page
basis. Everything including issues, MRs, file browsing. There was 800kb of JS
in the entire app before I joined as the first FE Eng. There is jQuery and
other libraries and our own code. That was the reason we wanted to remove
Turbolinks. So we don't load all the JS for the entire app at once. We want to
load things on demand.

Funny thing, I have built a full fledged production 2d/3d application in JS.
It was less complex than what GL has to do, and it was 670kb fully minified
and obfuscated. We are constantly looking for ways at GL to make our file size
smaller and our JS faster. It is something we are actively putting our time
towards.

~~~
jblok
Why do you need to use Turbolinks, when you can just do a normal page load,
and set the correct cache headers for your javascript bundles, to stop the
browser re-downloading the same script.

~~~
strken
This isn't specific to GitLab or GitHub, but turbolinks, pjax, and friends are
really useful when you have a lot of setup that can be shared between pages,
i.e. initiating a websocket connection, rendering a header with notifications
and an avatar in it, decompressing and parsing your js and css, etc., and you
don't want to implement a single page app.

When I refresh the GitLab sign-in page in Chromium, I see that the initial
page load takes 40ms to parse css, 250ms to parse and execute js, and then
another 70ms after DOMContentLoaded. This is with a warm cache. It's not
unreasonable to think that turbolinks might save about 300ms on page loads,
which is a respectable performance boost.

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

~~~
jordanlev
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 (whereas react seems to appeal to people with more of a straight-
up programming background). YMMV

~~~
ng12
> easier to learn

I think this is problematic because people don't differentiate between React
and the React ecosystem. Plain old React is just as easy (probably easier)
than learning Vue. I always recommend the official React tutorial
([https://facebook.github.io/react/tutorial/tutorial.html](https://facebook.github.io/react/tutorial/tutorial.html))
before even thinking about Redux or Webpack or whatever.

~~~
jordanlev
Of course it's subjective, and different people coming from different
backgrounds / experience levels find different things easier than others.

But... that tutorial you say you like to show people utilizes jsx, which needs
to be compiled with something (right? Or does react do the compilation
automatically at runtime now and I missed that memo?).

And for people coming from a place where they are very comfortable and
familiar with html and css, and maybe a light sprinkling of jquery on top, Vue
is _way_ more approachable than the tutorial you linked to.

~~~
spicyj
create-react-app is our recommended way to build simple React apps (and some
complex ones). It has no configuration and is designed to be very easy to set
up.

(My understanding is that Vue templates also need to be compiled -- is that
incorrect?)

I wrote the tutorial. Could you give any suggestions on how I could make it
easier to get into?

~~~
tomstuart
Not the OP, but I'll state the obvious on their behalf.

The number one thing that you (and Facebook) could do to help people learn
React, and combat the perception that it requires overly complex tooling, is
write a tutorial that shows how to use React entirely in-browser without any
build toolchain. A static HTML file, some <script> tags pointing at a CDN —
done. No distractions, nothing to download, nothing to install, nothing to
run, just a JavaScript library that makes it easier to write view templates.

It would make it even easier to get into if that tutorial were written
entirely in ES5, but you could use babel-standalone if you felt that JSX and
ES6 were important enough.

~~~
spicyj
Thanks for replying! Our official tutorial was actually exactly that for
_years_, but it didn't seem to help much. I get the sentiment though and maybe
we can find another way to make it work.

~~~
scrollaway
Offering an alternative point of view: I would really like if the tutorial at
least pointed towards documentation on what do I need and why, and the right
way to set these things up between Babel and Webpack, as well as Typescript.

Maybe my use case is rarer, I don't know, but if I want to do things right, I
want to understand what I'm setting up. Do I really need babel? If I use
Typescript, do I _still_ need it? etc...

I understand this doesn't have much to do with React per se but if these
components are a definitive part of the ecosystem people work with, there is
value in at least telling people where to find a high quality explanation for
how they fit together.

------
jcoffland
It'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.

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

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

~~~
bobbytherobot
I'll take a stab, although I don't share the same absolute stance.

I've run the gambit when it comes to types of front-end projects. The React
community has more focus on scaling React for large teams and companies. This
isn't to say Vue can't do any of this, but there is a clear focus in the React
community. I need to do isomorphic rendering because of SEO, there is a lot of
React documentation on that and very little for Vue. I need static analysis
for my code to prevent errors, Flow answers that. I need a replayable state
for debugging errors, Redux gives you that.

None of what I mention about React is its sole domain. You can list off many
alternatives.

Reading through why people choose Vue, many common needs come up. The one that
I find interesting is needing a system that Designers can understand because
they code up the HTML and CSS. I doubt that is something that comes up with
React teams.

In my opinion, if you require a framework, Vue and React are two great
options. It comes down to various small differences about your team needs.
(Please stay away from Angular though.)

~~~
burriko
I love both React and Vue, but I feel the need to step in and defend Vue a
little here.

Of the 3 points you listed, Vue has a section in the official documentation
dedicated to Server-Side Rendering, ditto for using it with Typescript for
static typing, and it even gives you replayable state with Vuex (the official
redux-style library for Vue).

They really are both great options.

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

~~~
hamandcheese
Yet much easier to do by avoiding a single page app all together.

~~~
williamscales
Is there anything meaningfully different between a site made up of a number of
discrete single page apps and one built with Vue?

~~~
__luke
Sure! Multiple discrete single page apps are simpler to develop and maintain,
especially for apps that have a lot of dependence on the backend. IMO it
promotes a healthy (aka obvious) separation of concerns and provides
flexibility. A UI framework like Vue helps us cut a lot of corners when we
need to, but no doubt, not every problem needs to be solved using the
framework, the ability to retreat to vanilla when you can is hugely underrated
IMO, especially given the _promising_ future of vanilla.

------
calcsam
There's an entire cottage industry of 3 to 5-year old series Bish startups
porting Backbone // jQuery apps over to more modern frameworks. We are moving
ours over to React at Plangrid (mostly done), Gusto is mostly done with their
migration as well. Would be interesting to figure out how many startups are in
this category.

~~~
muratk
We at engageSPARK moved from jQuery mess to Ractive.js, which we're quite
happy with. The UI components don't cause us much stress, because they're
conceptually simple. What gives us headaches now is the data flow (stores and
actions using reflux), so we're now thinking about remodeling this, and while
doing so moving to redux. The particular technology is less often the problem,
but how it's used, and that's been true for us, too.

------
craigcabrey
Misleading title, from the article:

> We are not rewriting GitLab's frontend entirely in Vue.

------
educar
Sorry to be negative but GitLab's performance is embarassing :/ It is so slow
and it's not clear why. Is this because of rails? Just seems very poorly
engineered.

~~~
irq11
GitHub is a rails site. Does the same thing, and is fast.

I don't know where people get the notion that rails is slow.

~~~
sandGorgon
there is a difference between scaling a rails application when you are running
a cloud business and running a packaged application on-site. I'm pretty sure
nobody is running gitlab backed by databases like AWS RDS or something.

I have shipped large rails apps as packaged software for on-site install
(using jruby). It's not easy.

~~~
irq11
I'm not sure what your point is. Rails isn't any slower when deployed on-site,
nor is it more likely to be a bottleneck.

If your local database is slow and the app code requires lots of DB resources,
then sure...but that's the app, not rails.

~~~
pythonaut_16
I think the point is that Gitlab faces unique challenges because anyone can
host Gitlab on their own hardware, so they're always trying to solve
performance problems in a way that any typical user could also solve it.

Github on the other hand can use strategies solely targeted at their SaaS
performance. It seems that Github also maintains more control over their
enterprise version than Gitlab but I'm not 100% sure there.

~~~
maccard
[https://gitlab.com/gitlab-org](https://gitlab.com/gitlab-org) takes 4 seconds
to load on my machine with a gigabit wired connection.

[https://github.com/github](https://github.com/github) takes ~2.2 seconds, but
by about 1 second has most of the information on screen and is simply waiting
for the activity graphs.

------
ZenoArrow
I'm not aware of the performance bottlenecks with GitLab, but are there any
plans to speed up the backend as well, such as moving to a faster Ruby
implementation?

~~~
jabl
There's another github/gitlab clone called gigs that's implemented in go.
Never used it myself, but if you want to save server resources I guess it's an
option.

~~~
gtaylor
*Gogs

~~~
jabl
Thank you, indeed it's gogs ( [https://gogs.io/](https://gogs.io/) )

Damn you autocorrect!

------
Tade0
I'm happy to see Vue in a project that I recognize.

To all the people arguing about JSX: Vue 2 supports it.
[http://vuejs.org/v2/guide/syntax.html#ad](http://vuejs.org/v2/guide/syntax.html#ad)

------
rubber_duck
No mention of TypeScript - I wonder why ? It's such a powerful tool when your
code base scales.

~~~
connorshea
We didn't go with TypeScript because we were burnt by CoffeeScript before.
People don't know TypeScript or CoffeeScript nearly as much as they know
vanilla/ES6 JavaScript. It's easier to hire for and easier to get contributors
for.

------
megawatthours
In webpack.config.js

> if (IS_PRODUCTION) { > config.devtool = 'source-map';

Ouch! This will make for a huge bundle. See
[https://webpack.github.io/docs/configuration.html#devtool](https://webpack.github.io/docs/configuration.html#devtool)

Merge request here: [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/9028](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/9028)

~~~
Androider
Surely the sourcemap is externalized to a separate file and only loaded if you
attach a debugger, if the sourcemap is even deployed to prod together with the
bundle at all (unlikely in my experience). 'source-map' produces much nicer
traces than 'cheap-module-source-map', and both type of maps are going to be
huge in any case.

------
wikyd
Are you using Webpack directly with Rails? I'm curious how your development
environment works.

~~~
__luke
Yep! webpack-rails gem [https://github.com/mipearson/webpack-
rails](https://github.com/mipearson/webpack-rails)

~~~
wikyd
Awesome, thanks! We're using this too, but have been thinking about making the
switch to
[https://github.com/rails/webpacker](https://github.com/rails/webpacker)

------
creo
GitLab rushing good news about frontend when backend crashes is good short
term PR support plan.

~~~
cmatija
We have separate teams working on frontend and backend.

Here's a list of performance issues which we intend to work on:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues?scope=all&utf...](https://gitlab.com/gitlab-org/gitlab-
ce/issues?scope=all&utf8=&state=opened&author_username=pcarranza&label_name%5B%5D=performance)

Most of them are scheduled for 9.0 or 9.1

------
jaequery
sounds like he never gave vue a try because thats also how i felt before
trying vuejs.

but once you go vue, you will be very happy you did. i see a lot of ex-react
devs who tell similar stories, myself.

with the sudden rise of vue and just how fast vue is gaining traction, given
the trends and lifecycle of frameworks, i wouldnt be surprised if vue over
takes react as de facto of frontend frameworks soon. it really makes
development much pleasant and faster.

------
benologist
Wouldn't ignoring the code have the same outcome if you upgrade servers next
year? Client devices will become faster too in that timeframe too.

------
kingosticks
> as our current development takes loads of time to refresh the page while
> developing GitLab

Really? What's 'loads of time' here?

------
andrew_wc_brown
VueJS is a lightweight version of Angular but has the same pitfalls when its
comes to being isomorphic.

React is an engineers overkill solution. JSX is bluck.

I use mithril.

------
omouse
Webpack is a mistake imo. Accidental complexity everywhere.

------
camdenlock
The escalating abuse of the word "awesome" is like the overuse of dynamic
compression in music. When every expression is fever-pitched, there's little
room for interesting expression.

I also notice that the most shameless abuse of "awesome" seems to come from
public-facing software developers, e.g. community managers and the like. It's
become some kind of advertisement for a bland, safe, comfortable community
where nothing is risked, and competition is frowned upon.

All right, I may have gone a little too wide with that, but AUGH, we need to
try way harder to increase our expressive range if we're going to be writing
articles that aren't exhausting to read.

~~~
jbigelow76
Make "radical" viable again?

~~~
toomuchtodo
Bodacious.

~~~
akhilcacharya
Tubular?

------
rkunnamp
We at [http://www.reportdash.com](http://www.reportdash.com) uses Backbone +
Backbone Layout Manager + Jade

Every time I see a post like this , I feel sad for being less cool. I try to
learn a bit of the mentioned cool framework. Then I realise, how awesome my
current set up is.

~~~
joering2
> Add On: Custom Domain with SSL - $50 per month

Great way to discourage companies from handling their data online in a secure
way.

Seriously with SSLs as cheap as $4.99 per year, your pricing feels like its
1999 all over again!

~~~
tyre
> with SSLs as cheap as $4.99 per year

*As cheap as Free Ninety Nine

[https://letsencrypt.org/](https://letsencrypt.org/)

------
40_pending
Vue really has the best of both worlds. You can use it like old-style angular
or take the component approach. You can just include the 71kb minified script
and take off or you can use a build system with components - Take a look at
Vue-cli: [https://github.com/vuejs/vue-cli](https://github.com/vuejs/vue-cli)

