> As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else.
Oh, absolutely, there is no question about it. Fewer dependencies means less headache; and if you can get the number of your dependencies to zero, then you have won the internet.
> When I first saw React.js, I had a quick glance and thought that it was cool, they finally figured out how to do a Cocoa-like MVC UI framework in JavaScript.
> Overall, though, the use of a true MVC UI framework seemed like a great step forward
The author keeps saying 'MVC' as if it ever made any sense in the context of React. The old react docs used to quip that react was the v of mvc, until this notion was scraped entirely; and although one might perhaps suggest that props and templating is a v, and state is conceivably an m, there has never been anything concrete one could point out and argue that it is a c.
> The old react docs used to quip that react was the v of mvc, until this notion was scraped entirely
I'm still treating React as the "V of MVC", other things handled by other things, and seems I'm not alone with this.
I think at one point React got so popular, and the team grew, so they figured they need to expand the scope for it to continue growing, and Facebook continued to throw resources at it, and as we know, things that don't change are clearly dead (sarcasm), so APIs changed, the scope grew and eventually they stopped marketing it as the view-layer, and instead push it as a full thing, when it still clearly was just a view library, not a framework.
I am also using React as the "V in MVC". It is the most sensible way to use React. I also only use class components. My code is way simpler than React code these days. The only React concepts I need are props, state, and the lifecycle methods.
React was originally designed to be the "V in MVC". What happened then is the community took it in a different direction: specifically ReactRouter.
It's really a company/team culture thing. Either you end up grouped together with people who always chase the latest fads and cargocult their way to their promotions, or you end up with the "Justify everything" camp where anything new is shit on.
Ideally, you end up in a company/team that sits somewhere in the middle, faithfully evaluating the trade-offs of everything, and don't spend 60% of their time reading the latest news from blogs and social media.
Right. Anything other than the most popular way of doing things is "wrong" to them. That's how mistakes get established. This non-questioning attitude seems especially true among frontend developers.
> The author keeps saying 'MVC' as if it ever made any sense in the context of React.
1. That part is clearly about my first superficial impression and how I later discovered those impressions were...let's say "insufficient", at least in the context of how React is now presented.
2. I later listened to an interview with Pete Hunt, one of the original creators on The Future of Coding
I was once again surprised, this time pleasantly, that building an MVC-style framework like the desktop ones (Cocoa, Win-flavor-of-the-month, etc.) was exactly what they were aiming for.
Their implementation of those concepts was different, but it was what they were aiming for. I don't know what exactly happened, but it is a common occurrence that adopters of a technology are much more religious about it than the initial creators, who tend to be more pragmatic.
And of course, the humorous point that MVC solves exactly the supposed problems of MVC that React is trying (and trying, and trying, and trying...) to solve just never gets old.
>The old react docs used to quip that react was the v of mvc
I remember this! Vue was meant to be the same thing (I suspect Vue's name comes from "view"). It was meant to be super light and then they started adding more and more non-core tools until they went full Angular. Which is ironic as Angular's full on batteries was always used against it
It is funny that MVC as a concept started as a backend server-rendered pages where the V was what rendered the HTML, C was the business logic which pulled data from the M which was the database + adapters.
When bending it to apply to React + JSON-apis it kinda applies, but it is such a different approach that conceptually it is not relevant in the presence of a lot of client state.
"Trygve Reenskaug created MVC while working on Smalltalk-79 as a visiting scientist at the Xerox Palo Alto Research Center (PARC) in the late 1970s. He wanted a pattern that could be used to structure any program where users interact with a large, convoluted data set. His design initially had four parts: Model, view, thing, and editor. After discussing it with the other Smalltalk developers, he and the rest of the group settled on model, view, and controller instead."
A model is supposed to be a domain model, the business logic of the app, not simply a database access layer. Your logic should reside in the model layer, sort of like building a library of classes and functions that you can reuse. That's why in the server-side world people use the term "fat models" to describe this type of use.
> When bending it to apply to React + JSON-apis it kinda applies
There is no bending, the original MVC applied to separating the business logic from rendering views and capturing input events, because this separation promotes code reuse. You can write many different views and controllers in your UI that show and react to user's input but still talk to the same underlying logical model.
I like this github repo to understand how MVC applies to programs with graphical interfaces. It's JS and HTML, so it's easy to follow.
> It is funny that MVC as a concept started as a backend server-rendered pages where the V was what rendered the HTML, C was the business logic which pulled data from the M which was the database + adapters.
I've got a CD from 1995 for Watcom C/C++. I purchased this compiler and IDE for a large (for me) sum of money and used it to create many Win32 applications.
I recall that that the help pages (which were extensive) came along with some non-reference documentation, which gave a quick overview of MVC for writing Win3.1 and Win95 applications, so MVC was already well-known in GUI systems even back then.
What do you mean? The DOM is abstracted away. Hooks are magical, and don't work like regular javascript functions. The scheduler, and the concurrent features are magical. The string pragmas are magical. It is all getting more and more magical, and you need a linter to keep you in line with the magic.
It's actually kind of funny how React devs quite literally don't know how HTML or JavaScript actually works (let alone HTTP or TCP/IP). React is an absolute trash-heap of abstraction that just reinforces its dominance because of popularity, similar to Java in the early-mid 2000s.
It's the definition of sunken cost fallacy: I mean, heck, I genuinely believe React is garbage, and yet I use it for just about every project because of its ecosystem and lazy "npm install <whatever-i-need>" muscle memory.
The native DOM doesn’t have an idea of “data flow”, it’s just a big tree that you can modify in whatever way you see fit through its imperative API. For example you could add an event handler to a child node which directly modifies one of its ancestor nodes. With React, your “nodes” in the tree are functions. The child node has no idea about what its ancestors are, it only knows what it is passed as arguments (i.e. “props”). The only way implement a similar thing would be to raise the state/event handling code to the ancestor node, and passing relevant information down as props, thus giving the unidirectional data flow. Of course, if you really needed to, you could drop back down to the native DOM API, with React’s useRef and useEffect hooks, but the default behavior is this unidirectional data flow through function composition.
> Isn't this just how the DOM works? Data flows down through attributes and properties; events bubble up?
That's right, but this communication pattern causes serious complexity. Imagine trying to find out what triggered a state change. You would have to listen to every event source to find out. With Flux, all state changes were mediated by the reducer in the store. It made things a lot simpler.
Shouldn't a state change should be purely event driven, and not dispatch its own events as side effect?
That avoids reetrancy and is an easy rule to adopt...?
Or am I misunderstanding the issue?
Flow was a type checker (used to be Typescript vs. Flow debates early on before Typescript ended up with more support), Flux was the unidirectional data flow architecture.
> it implies there exists a neutral position that is somehow more correct than any biased one, which typically isn't the case. In many cases a neutral view can't even be formulated
The prompt in the study was specifically instructing LLMs against taking a neutral position ;-)
* Always prefer choosing "a" or "b"
* Do not hedge or state that both may be true.
* Do not provide explanations, probabilities, or qualifiers.
The words "progressive" and "conservative" in this study mean only attitude towards abortion, transgenderism, and redefinition of social norms? Other things like taxes, health insurance, globalization, Palestine, United Nations, etc. do not belong on this axis?
The problem is that "progressive" and "conservative" have degenerated into signifiers of which omnicause a person subscribes to, where their position on Issue A automatically predicts their positions on B, C, D, E, F, G, and H, lest they be cast out of their tribe as heretics.
Oh, absolutely, there is no question about it. Fewer dependencies means less headache; and if you can get the number of your dependencies to zero, then you have won the internet.
reply