Hacker News Reader

Comment by jorblumesea | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

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.

Do you mean lighterweight as jQuery or VueJS/React?

I ask because I'm having a major FUD of using VueJS in a small (tiny) project - I don't seem to be able to think in those terms yet, and I don't really use npm (those starter projects generate 1000 files...).

I'm from the time when you would just list JS files in the HTML..

Can't you use supporting libraries for more advanced stuff? Use Vue for the view layer, vuex for state handling, vue-router for routing and vue-resource for ajax, I feel that it is faster (as in dev learning time) to write an app in Vue without knowing any basics of Vue/front end dev world, I know this because I wrote this app, http://github.com/thewhitetulip/Tasks-vue as I started to learn Vue from the docs, later, I started to write a tutorial as I learned it, https://github.com/thewhitetulip/intro-to-vuejs/ because there is no such resource which taught from the newbie side.

I didn't re-invent the wheel, it is just like what we usually do with Go, we don't use a framework, but a toolkit.

> Examples being history management and back button, state management (especially if you prefer immutability), and server side rendering.

Maybe/maybe not, I use a Mini-SPA approach where I pass down libraries.js, bundle.js and foo-page.js (all minimised and such) on the initial page load I pull the data and pass that down as well (avoiding the round trip).

With that approach I get most of the benefits of an SPA in terms of behaviour but without having to use client side history management and I don't break the back button.

I still get to issue calls and such and the actual orchestration of the page side js is done with a very light class that each page extends from that has just a handful of methods.

Component orchestration is managed with pub/sub.

I've found it an extremely nice way to develop, there isn't a massive duplication of code and it's very easy to reason about, it lacks a few of the benefits of a pure SPA but has most of them and the separation is very easy.

I know you just listed some examples but I think many on HN place frameworks too highly. They're useful if they can make you more productive but many of the items they cover are not that difficult to substitute or attack from another angle.

> Examples being history management and back button

This is already built into the DOM API since HTML 5 (you can use hashes if you want to go old school as well). So you don't need any special library or framework to handle this for you.

> state management (especially if you prefer immutability)

Well, depends on what you mean by state management. Do you mean if you go forward and back the browser will reload what you already entered? The browser will keep state in some scenarios. In others it's simply storing it and reloading it.

It's not like this is difficult or anything. Most frameworks require setting this up in various ways anyway.

> server side rendering

I would argue server side rendering is far easier without a framework. Without a framework you can load templates from the server side that have data already injected and ready to go. The JavaScript front end just deals with it.

Maybe by Vue they mean Vue + vuex + Vue router.

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

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

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

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

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.

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

The issue you linked to was moved to 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&utf...

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.

I hate writing react. I have much more enjoyable experience with vue or riot.

> I hate writing react.

Out of curiosity, what was the straw that broke the camel's back?

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.

Yeah, the main problem with React is that you actually want React+MobX, not React+Flux :)

Thanks for sharing. Enough people are hopping onto the React → Vue train for it to be worth looking into.

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.

Reply on news.ycombinator.com