It's RPC. Remote procedure calls. An approach that has made a comeback in the front-end space recently. There was tRPC; then react made a splash with the release of its server components; then other frameworks started emulating the approach. I think Svelte now has something similar with its "remote functions". And Solid has been working on something similar; so that SolidStart now has a "use server" pragma. They probably don't replicate React's protocol; but the idea of calling functions on the server is similar.
> An approach that has made a comeback in the front-end space recently.
It wasn’t really a “comeback,” RPC never lost popularity. We just called them “REST” APIs that were a barely disguised adhoc JSON RPC format with a few CRUD verbs tacked on for routing requests.
You aren’t wrong. I basically stopped using any OSS code backed by Google as a result.
I’d pushed Angular over React[0] for a massive project, and it worked well, but the migration to Angular 2 when it came created a huge amount of non-value-adding work.
Never again.
I don’t even really want to build anything against Gemini, despite how good it is, because I don’t trust Google not to do another rug pull.
[0] I’ve never enjoyed JSX/TSX syntax, nor appreciated the mix of markup with code, but I’ve subsequently learned to live with it.
No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.)
React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects.
Ecosystems sometimes undergo a phase-shift. Sometimes they take a long time, based on the size. Python 3 was released in 2008, just a year before Angular 1. And the last Py2 release was in 2020, about 2-3 years before the last AngularJS version. (And of course there are many businesses running on py2 still. I know at least one.) These things take plenty of time.
Angular1 was pretty opinionated, willing to break with the tradition of just add one more jQuery plugin.
Miško was working at Google, he persuaded some people to take a look at the framework that he and Adam Abrons were tinkering with.
Angular 2 was announced in 2014 January. And then v1 still got years of support, even the component architecture was "backported" around 1.5 (in 2016?)
You can run old v1 code side-by-side in a v2+ app up until v17. (At least the v17 docs describe the process in full and later docs link to this page. https://v17.angular.io/guide/upgrade )
...
Google did a pretty good job IMHO. Google throws products under the bus, but not so much OSS projects. (Though the sate of AOSP comes to mind.)
> Google throws products under the bus, but not so much OSS projects.
It abandoned the Material Design web components project, which, I think, attracted some Polymer people.
Speaking of Polymer, it has evolved into Lit; but I understand there is no more support for that project from Google. Lit has joined the OpenJS foundation to stay afloat. The Googlers that used to work on Lit, and on Material Design web components have mostly left.
Also, remember the Workbox project? A simple setup for service workers? It's barely alive.
The angular material design library is so much better than the react one. And it is supported by google. The material CDK is amazing to create custom components easily
I think JS is still overall more popular than TS, but if your team forces TS then yeah. It's like Java devs reluctantly switched to JS and were like, this needs more boilerplate.
Yeah, I spent years in Java and then even longer in .NET and it felt like everything I was getting a bit fed up of in those worlds had invaded JS. 20 years ago I could never have imagined defending JS as a language but, as time wore on, I started to appreciate its more stripped back syntax. And then a lot of what’s been added in later ES standards has been great so it seems even more unnecessary to layer TS on top.
It was one hell of a ride, but I would say the Angular team did one hell of a job too, supporting the glue code until v18 (not sure if the latest version still does).
Having both old and new Angular running in one project is super weird, but everything worked out in the end.
Well, the official statement is that 1 and 2 are 2 different frameworks. That’s why they were later named to angular JS and angular, to avoid confusion.
The migration path between angular 1 and 2 is the same as react and angular, it’s just glue holding 2 frameworks together
Easy migration was promised but never delivered. Angular 2 was still full of boilerplate. “Migrating” an AngularJS project to Angular 2 is as much work as porting it to React or anything else.
So yes, people got burnt (when we were told that there will be a migration path), and I will never rely on another Google-backed UI framework.
For people with social or performance anxiety, it could be just the opposite. In fact, I'll wager that some people diving into an extensive study of leetcode problems are doing it to procrastinate attending actual technical interviews. ("I'm not quite ready yet, gotta make sure I don't blow any interviews.")
That's been me before. If you're wondering why people ghost at the technical when they seemed like great candidates: sometimes, at least, they like engineering because it's a discipline where they can get things "right" within some defined band / acceptable tolerance. In interview context, where there's somebody watching and judging, the degree of tolerance is unknown, and you know you won't be given time to choose the most correct approach regardless, and that solving the technical problem is just an indirect proxy for solving the "is this person a good social fit" problem (because you know you have the technical ability), all acts as anti-motivator for practicing for leetcode style interviews.
Its easier to say "I just didn't study and that's why I didn't get the job" than it is to say "even though I spent a bunch of time optimizing for this interview scenario and know I absolutely aced the technical interview, they still didn't like me."
Heck, I've been in interviews where I found the technical aspect a relatively easy bar to pass, and I blurted out something strange just to sabotage myself. If they can look past that and still see that I know what I'm doing and bring a lot to the table, I know they are people that I can do my best work with without needing to be constantly second guessing myself in conversation.
Some companies seem to forget that interviews go both ways, and that job candidates are screening for something different than what companies are screening for.
The fear of failure also comes from the concept of "cool-off". I recently failed a coding challenge in Zoox only to find out after the rejection that the cool-off period is 2 years!!
I would have never applied to Zoox had I known up-front that I'd have to wait for so long to interview with them again.
> - The homepage right now is extremely lightweight and uses next to no javascript. The new design just looks like the same generic Starlight template
I'm not sure we want to use a javascript framework. While it provides a lot of features, bitrot in the javascript ecosystem happens at a very fast pace (and pulls in thousands of dependencies). I have sites written both in gatsby and vuepress and between major version breaking changes and deprecations as frameworks cycle, it's a ton of work to keep up (e.g. vuepress -> vitepress/vuepress v2). Even mdbook upgrades have been a pain since we need to merge down theme updates. I'd prefer to see something simple, e.g. (https://docs.racket-lang.org/guide/). What do we do in five years when Starlight is deprecated by another framework, and Astro is several major releases ahead, with breaking changes?
This is a very valid point, and a mark of a mature developer who has been bitten by frontend churn, and wants something stable, simple, reliable, and predictable.
> Browsers and servers impose practical limits on URL length (usually between 2,000 and 8,000 characters) but the reality is more nuanced. As this detailed Stack Overflow answer explains, limits come from a mix of browser behavior, server configurations, CDNs, and even search engine constraints. If you’re bumping against them, it’s a sign you need to rethink your approach.
So what is the reality? The linked StackOverflow answer claims that, as of 2023, it is "under 2000 characters". How much state can you fit into under 2000 characters without resorting to tricks for reducing the number of characters for different parameters? And what would a rethought approach look like?
Each of those characters (aside from domain) could be any of 66 unique ones:
Uppercase letters: A through Z (26 characters)
Lowercase letters: a through z (26 characters)
Digits: 0 through 9 (10 characters)
Special: - . _ ~ (4 characters)
So you'd get a lot of bang for your buck if you really wanted to encode a lot of information.
Unless you have some kind of mapping to encode different states with different character blocks your possibilities are much more limited.
Like storing product ids or EAN plus the number of items.
Just hope the user isn’t on a shopping spree
> 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.
pnpm doesn't execute lifecycle scripts by default, so it avoids the particular attack vector of "simply downloading and installing an NPM package allows it to execute malicious code."
As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.
> 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.
It's RPC. Remote procedure calls. An approach that has made a comeback in the front-end space recently. There was tRPC; then react made a splash with the release of its server components; then other frameworks started emulating the approach. I think Svelte now has something similar with its "remote functions". And Solid has been working on something similar; so that SolidStart now has a "use server" pragma. They probably don't replicate React's protocol; but the idea of calling functions on the server is similar.
reply