Has anyone noticed that the response for the blog page has a header: "x-robots-tag: noindex, nofollow"? What's the purpose of this header on a content page?
UPD: Sorry, never mind, I inspected a wrong response.
What does this mean? I suppose it can't literally mean equal opportunity, because people aren't equal, and their circumstances aren't equal; but then, what does this mean?
A clear definition is definitively hard to come by, but I will share what I see as rather large issues that impact society: minimal spending per children for education to allow a good service for most (this will imply that smart kids are selected and become productive as opposed to drop out because they had nobody to learn from); reasonable health availability for children such that they can develop rather than being sick; sufficient food for children to support the first two (can't learn or be healthy if you are hungry).
Currently I know in many countries multiple measures/rules/policies that affect these 3 things in ways that I find damaging for the society overall on the long term. Companies complain they don't have work forces, governments complain the natality is low but there are many issues with raising a child. Financial incentives to parents do not seem to work (for example: https://www.bbc.com/news/world-europe-47192612)
No. I did want to pick something facebook inspired though. I like fate because:
* facebook’s original developer conference was f8
* It kinda works well for fulfilling (data) requests
* It’s similar to face
* It’s short and memorable
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 took me a while to appreciate JS too. Thought it was just the beginner language until I used it. Also had to learn the hard way that a web backend is hard to do efficiently without an event loop.
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.
UPD: Sorry, never mind, I inspected a wrong response.
reply