Hacker News Reader

Comment by jeswin | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com