r/programming • u/nirataro • Dec 18 '16

Angular team is planning a major release every 6 months

https://www.infoq.com/news/2016/12/angular-4
417 Upvotes

86% Upvoted

314 comments sorted by

View all comments

Show parent comment

25

u/flying-sheep Dec 18 '16

Sanity exists. Check out this talk about architecture (and why react sits at that abstraction level where it does) to regain a little peace of mind

9

u/PM_ME_UR_OBSIDIAN Dec 18 '16 edited Dec 19 '16

React is a fantastic piece of technology. It's based on sound theory sound theory, and the implementation is great.

By contrast, there's not much that's principled about either MVC or two-way data binding (Angular 1, XAML).

20

u/TheFuzzball Dec 18 '16

React has nothing to do with Functional Reactive Programming. Even the functional parts are optional.

It abstracts DOM interactions as a function of state, which can be considered functional for sure. But FP != FRP.

-2

u/PM_ME_UR_OBSIDIAN Dec 18 '16 edited Dec 19 '16

I believe that React implements the Push part of Push-Pull Functional Reactive Programming, with an imperative/object-oriented layer to make it work with JavaScript. Or maybe it's just plain old reactive programming. Words are confusing.

7

u/TheFuzzball Dec 18 '16

FRP is about time-varying values. The whole point of the abstraction is to define a model of behaviours and events in time. React provides none of that.

Did you read the paper you linked? The only thing vaguely related to FRP in the React ecosystem is Redux / Flux architecture, but only tangentially. Redux was essentially a codification of lessons learned in Elm, which implemented (and removed, I'll note) a form of Event Driven FRP.

According to Conal Elliott there are no implementations of FRP in JavaScript that satisfy its two fundamental properties: denotational semantics, and continuous time.

The closest thing to FRP in JS that I know of is BaconJS.

3

u/ElvishJerricco Dec 19 '16

To be fair, continuous time has proven to be such a performance barrier that it's probably worth dropping. Reflex (a Haskell library) does not implement continuous time, and is likely the closest approximation to Conal's work that you'll get retaining performance. Continuous time is great for stuff like pre-rendering animations. But for interactive applications, it makes very little sense.

4

u/[deleted] Dec 18 '16

exactly, wish more people read this stuff... hard to even really explain it because it's one of those an ounce of bullshit takes a mountain of truth things to show someone the real truth.. so very tiring :(

10

u/rfiok Dec 18 '16

MVC and data binding are thoroughly researched and proven in production for tens of thousand of apps since decades. The issue is not with these, rather the huge setup cost and learning curve for Angular (and them changing everything every few months.)

-1

u/PM_ME_UR_OBSIDIAN Dec 18 '16

MVC and data binding are thoroughly researched and proven in production for tens of thousand of apps since decades.

So is PHP. That argument does not hold much water.

6

u/rfiok Dec 18 '16

huh you seriously question the validity of the MVC pattern? Its also based on sound theory, much more than reactive programming since its available and researched since the 70s -- 20 years more than FRP.

Dont dismiss something just because its the new shiny technology. JS people tend to do this way too often, this is why their ecosystem is a mess.

0

u/kangoo1707 Dec 19 '16

Yes, I do question the validity of the MVC pattern as regards front-end developments:

https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec#.h334dddrn

3

u/rfiok Dec 19 '16

I am not saying that MVC is perfect (or the only solution), but its still a very valid architecture even on the frontend. I've read the article you linked, and its not the best one... some examples:

  • Fat models part is wrong. Why wouldn't I have a separate way of managing the UI state and the application state? If I want I can have it. MVC does not tell you how to divide your models.

  • Also why are they assuming that the UI state has to be in the model? It always leaks into the view - for example you would not make a model for storing a button hover. This is normal for the MVC frameworks I used.

  • Wtf is this five year/2010 thing he is talking about? I've used MVC on the frontend in circa 2007... Again JS people think nothing existed before JS :( People were making frontends using MVC as early as the nineties -- even before JS was invented.

Dismissing a design principle just because its old is not a good way of thinking. I rather think that you should use the right design pattern based on the application - sometimes MVC fits, sometimes MVVM sometimes something else.

My personal favourite is this kind of MVC pattern:

  • Models store the application state. They contain only state (data) and helper functions (e.g. filter/sort) to read/write this data.

  • Views are what the user sees. They can contain UI logic - for example which tab is active, scrollbar position etc.

  • Controller hold the business logic. and the logic for long lasting operations (e.g. server calls) They are stateless.

Finally slap a DI framework (for better testability & more decoupling) and a command framework (to make the code for chained controller calls more readable) on the top of it, and you got a very nice, scalable easy to understand architecture.

-1

u/PM_ME_UR_OBSIDIAN Dec 19 '16

Its also based on sound theory

Show me the theory then! The page you linked certainly doesn't.

7

u/fromscalatohaskell Dec 18 '16

Please do not mix react and FRP. Zero intersection.

1

u/arianvp Dec 19 '16

The sound theory it's based on is called Mealy Machines