React is more like 'Lambda the Ultimate Web Component'.

A component is almost a function returns element. Expanding a component is like calling a function and give it the property.

So you can have some abstract common behavior in HOC f and g, then you can have HOC `h = compose(f(g))`.

A quick comparison with Angular: @Component({template, style}) seems composable if we stretch a lot. But why make template and style in the decorator... They are not something we consider most abstract at all.

The function is the simplest yet composable abstraction over the template, Cheng Lou also has a really excellent talk on the topic: https://www.youtube.com/watch?v=mVVNJKv9esE&t=1470s

We can only hope that Guy Steele swoops in and saves the day by implementing React in hardware!

https://news.ycombinator.com/item?id=8860722

The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in:

http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c...

Design of a LISP-based microprocessor

https://dl.acm.org/citation.cfm?id=359031

Also according to Wikipedia[0] Brendan Eich was supposed to create 'Scheme in browser' but in the end it became scheme with Java syntax. I always wonder if it was real 'scheme in browser' the web would advanced faster, at least S-expression is good at expression HTML. Therefore we wouldn't have to wait JSX until 20 years later...

[0] https://en.m.wikipedia.org/wiki/Brendan_Eich

whether getting a component via a function call, vs an named export identifier (component class) - They have essentially the same net benefit over time.

A function that returns a component has no more reusability than a component class' identifier. That component itself has a very narrow use case of it being a UI component.

Composable, yes, but functional as in functional programming, no.

Functional programming folks love React- Pretty much every clojure web framework is built on React. But yes, with some effort you can come up with a definition for "functional" which React will fail to meet.

I'm confused, I wasn't being pedantic about React. I was talking about frameworks like Angular that don't try to be purely functional.

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^)

Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as well. We have a webpack installation that pulls in the Vue files and bundles everything and it is quite clean.

I've never understood how people view the separation of template, styles, and business logic into separate files as simpler. Now, to work on a single component, I need to open three files in my editor, instead of one.

The "separate files" argument is a red herring. It is really about separate "mindsets" or "modes of thinking".

In effect, JavaScript logic tends to be procedural/imperative, while templates allow declarative semantics, and styles are nearly a 2.5D constraint language. "Separation of concerns" here means only having to think in a particular mode, rather than blending all of those modes of thought into a single eyespan.

Notably, Vue allows for single-file components, while preserving the familiar and intentionally designed separation of declarative (HTML), imperative (JavaScript), and aesthetic (CSS) code.

I don't see how separate files forces you to think differently. It might aid in that effort, but it likely doesn't force it.

It is an over reaction to bad PHP.

Bad PHP pages mixes all kinds of shit together. This leads to the thought that to do it 'good' everything needs to be seperated.

It's a wrong thought but I see how people got there.

In vue (or atleast the way the majority of people use vue), each component is separated into a .vue file. That component's template, style and business logic is all encapsulated in that one file. A basic .vue file starts out with <template></template><style></style><script></script>. It keeps everything nice and simple, in my opinion. Each different "mode of thinking" is separated out, but still all together in one file.

Vue's 'separation' is a myth.

I don't know why people keep believing that separating templates and js is a good thig. Pete Hunt addressed this in the React into videos he did -

you want 'separation of concerns', not 'separation of technologies'.

React does the former. Vue/any other templating engine does the latter.

Check out web components with LitElement and lit-html.

You get a very React-like experience with components and functional templates in JS, but it's all standard JS, and there's no framework, just standard web components. The lock-in and risk is very low for enterprises.

Went down this rabbit hole yesterday and played with LitElement/lit-html for the first time... great experience for folks who don't want much "ceremony". Was also SUPER impressed with AppRun.

The more that I depart from my "bare metal" web tooling the riskier/dumber things get. I always want to see a path back to a basic HTML5 shell, driven by almost-pure JS (w/tiny helper libs), and basic CSS. Just like basic UNIX tooling - basic web tooling just works!

To those thinking about trying lit-html; it IS as simple as the example on the GitHub project page. I was able to build it into a semi-complex application within a couple of hours and it had massive performance payoff w/o compromising how I want to build things. It definitely gets my "KISS" approval stamp.

They allow you to use anything you want, as long as it's not React?

I am very curious about this kind of decision. I realize you may not be able to share details, but whatever you can share would certainly be interesting.

My company permits Vue and Angular, but not React. It isn't based in legal reasons, though.

Probably not WHATEVER, but what's approved by legal. React currently isn't because of the license/company that owns it I believe.

Well, the _license_ certainly shouldn't be an issue at this point. It was changed to a standard MIT license a couple years ago, same as all the other major JS frameworks.

If your company has issues with React being developed by Facebook, that's an entirely different question.

There was a license controversy a couple of years back, yes, but that was solved rather quickly - I understand that you as an intern don’t necessarily have any sway over legal, but they’re not up to date.

I personally enjoy using Angular, but yeah, Vue is your best bet!

Vanilla JS with a good understanding of MVC serves quite nicely in most cases. I wrote a few introductory programs to clarify it (https://github.com/madhadron/mvc_for_the_web).

What about Preact :)

Great suggestion. Preact is only 3kb so your users will appreciate it too.

Throw RiotJS into your eval queue too - I like it a lot

Why don't they allow react? One reason I can think of is they have a server side side rendered architecture and they want people to continue to use that. They don't want new devs to use company time to buff their resume with unmaintainable learning front end code. At least that's why I generally shoot down attempts at using FE js frameworks over here. We have some really awful react 0.11 pages that are years old that will take weeks to redo properly.

Anyway, my point is you might want to check if it is okay to use any FE framework at all. It seems like a very strange policy to say "you can use any FE framework except React".

But if you are going to do this use Vue.

Legal reasons.

The patents issues was FUD, but now it's completely irrelevant, the patent clause was removed a while ago.

Other projects in my company are still using Angular 1.x and Backbone. I guess it depends on your definition of modern.