That might be because of translations from Arabic. The article was also posted on a different website where the author responded
> the Kashida section was contributed to this post from a talk in Arabic of Nawal Hadeed, which she translated and added to the post herself. Although I'm unsure of LLM usage in the translation process, looking at the original Arabic I felt some change in tone while editing the post. I could have either declined the translation and never have this documented, procrastinate in translating it myself (which has been ongoing for a while), or publish as it is. I found the last least damaging.
While purists will disagree, a little bit of javascript is fine. Having said that, you are talking about a personal website. Most companies will have a backend of some sort anyway.
Also, here is a little secret. If you want something that is future proof, try something that has been around for decades and still runs large parts of the internet. People will scoff at this, but PHP is actually really neat for personal websites and has been for decades.
A while ago I also found myself looking at static site generators, workflows from github to my host, etc. Eventually I realized I don't update things nearly enough, don't blog, etc.
For similar reasons as you I didn't want to go completely static as that is just too much hassle when doing multiple pages. So I decided to utilize that good old lamp stack to basically do something like this.
Slightly more, but the base principle is the same. Just 10 lines of php code, and now I can just add pages by uploading their contents and adding them to the json file for whitelisting. For your use case it would be trivial to add a menu based on the json file and I'd be confident that it will still work in 10 years with minimal adjustments.
As a bonus I also rediscovered PHP in itself works really well as a templating language (as you can see) so no need for extra stuff like handlebars. As an extra extra bonus, I can just go to any shared webhosting party and get it running with no issue at all.
I am not saying you'd need to go down this road. But I just want to illustrate how stupidly simple a website can be with "old" basic technologies even if you want some form of backend.
I feel like there is some context missing in your story here. There is a lot of middleground between heavy SPA frameworks and creating everything from scratch. More importantly, I am left wondering what sort of functionality was your team trying to build that requires that much interactivity? At least that is what I assume with "rich user experience"?
If I had to guess, they were probably wanting to implement something like animations into the UI. Animating a list of items onload in a staggered format is still basically impossible unless 100% of your users are using Chrome. With a JS animation+component library, this type of animation is pretty much plug-n-play.
When the startup is trying to attract customers and also impress investors, sometimes there is a lot of effort spent on the investors just so they keep putting money into the machine. "See! We have an ultra modern/sleek site so it must be some other variable that is causing customers to churn..."
> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.
If 2009 is too far back you can try your luck in 2012 with Firefox OS.
Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.
The amount of effort that goes into keeping Termux barely functional, has a lot to do with Android and the platform making it harder and harder, to access a dev environment on a phone.
Running `npm install` on Android isn't so easy.
(Caveat: The new Android Terminal that only works on a handful of models.)
No that's not correct, they both support PWAs with a large feature set. I built and have been maintaining a client's PWA (an internal tool for their employees) for over 10 years now.
Not my site, but someone on HN (can't remember who) built it: https://pwascore.com
Even those results have a lot to be desired, it is just buried deeper in the insanely verbose research report and impressive looking amount of sources you see move past.
I recently have had a close look at the various "deep research" options the big three (Anthropic, OpenAI and Google) offer. None of them are exactly transparent about how they perform searching other than the "research plan" the present upfront the and shitload of sources they show you (which, to be frank, seems to be clever UX/marketing to make it look extra legitimate and impressive). Which is already a worrying sign to me, as you can't audit the process itself properly. But even with the lack of information available on the front-end I can still see enough that worries me. A few examples:
- "Sources" are taken at face value almost no critical look at the validity of the source, the context it is placed in, etc.
- A lot of sources I know are legitimate are rarely included while a lot of listicles, low effort "reviews", etc do make the cut.
- In multiple instances when looking closer at the research plan and the "hints" they show during searching it becomes painfully clear that often enough they start with an answer in mind based on training data and try to validate that rather than actually researching the data itself.
- Subtly different prompts that by all means should still produce the same factual outcome actually provide wildly different results. This one probably relates to the other points.
In addition to all of this, I also am 100% convinced that AI powered search is incredibly expensive[1], more so than traditional search. In my mind this increased cost eventually will need to be paid by someone, which likely is going to be the user. Since the process is non-transparant I am not confident that the results will not end up being polluted by sponsored deals, etc. There is simply no way in my mind that this is going to end up well for us users.
[1] A while ago I have experimented with creating my own deep research flow with the idea that I might be able to do something with local models. To limit costs I used a SearXNG instance for searching, setup playwright for browsing sources. Using an agentic flow with agents making all the various calls and dispatching other agents ended up eating A LOT of tokens. Even when I did switch to a non agentic flow where each step is orchestrated by code calling on LLMs with simple prompts to validate results still ate a metric ton of tokens for the simplest search query. Mind you, this was not even doing actual deep research but only a few simple search queries. Ironically, google models also did seem to have more trouble coming up with good search queries compared to other models.
> And to be fair 2: The other package repos also suck.
If you mean other languages, then yeah a lot of similar issues and weirdness there as well. Maven dependencies in any complex project are a "fun" challenge as well.
Though the sort of recurring supply chain attacks you see within the npm ecosystem is something I haven't seen elsewhere to this degree.
In this case they seem to be firmly closing the path though
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.
> There is no support for accessibility for the visually (or otherwise) disabled in KDE Plasma's wayland extensions (and none in core wayland at all
Can you clarify what you mean by this? In the process of KDE implementing Wayland support I also have seen several issues and blog posts dedicated to accessibility features. In fact, I am fairly sure I saw KDE explicitly funding accessibility development in relation Wayland a while ago.
I am using KDE with Wayland and just had a look in my settings and the Accessibility menu is there and the features in there also appear to be working. Including the screenreader which worked on all windows I had open at the time.
Which makes sense as none of that goes through the display server but rather a D-Bus protocol implemented by Qt and GTK as far as my understanding goes.
There is a bunch of stuff that came with X11 "for free" like access easier screen capture for magnifiers, input injection, etc but as far as my understanding goes KDE (just like GNOME) has been working on DE specific implementations of each.
I am not saying things are perfect right now as far as accessibility goes. I am not someone who depends on these features. I also know that things are in fact not perfect across the board and there is still work to be done. But the claim that there is no support for accessibility seems like a rather large hyperbole to me.
> So what ends up happening is seniors become more heads down, getting things done, and juniors struggle to get time with more experienced coworkers.
I just replied further down ( https://news.ycombinator.com/item?id=48353154 ) about this. You are entirely right, but it is also something that can largely be mitigated if companies and teams are self aware enough. I am not going to rewrite that entire comment but in addition to what I wrote there any self respecting company over a certain size should still have a junior training process in place that spans at least a year possibly two. Letting individual teams or even individuals figure out how to handle juniors always would give you wildly different results, but being in the office this was often hidden because some juniors would organically find other people for support.
If you are not physically in the office you need to make sure they have other check-in moments with each other. Allow for moments where they can meet people outside their teams (knowledge presentations, workshops, etc).
I still think working hybrid (but one day per week imho is often enough) is the sweet spot for many reasons. But overall I mostly think that the FT (as often) is making excuse for things that boil down to "no, the main reason is actually corporate cost savings and refusal to invest in core processes".
From a different perspective your sample size is just one, your team/company.
I started in a whole new team (as a senior) remotely during Covid which also contained juniors. They did incredibly well and were able to reach anyone remotely with no issue.
What might have been different is that the entire team was new and we knew we had to focus on our communication online and think about effective ways to do so. Which also benefited the juniors in the team. Many teams and companies never really gave it that much thought to begin with and I still see teams struggling to work remote at times. But, after giving them some pointers they often manage to do a whole lot better.
Some basic things out the top of my head that have benefited teams and juniors specifically:
- Have a "working together" channel where people can start meetings and where anyone can join if they feel like it. It often ends up being used by people who either like working together or those who can use some overall input on what they are working on.
- Have social online moments as well. One team had a 15 minutes social block in front of standup's an other team had just a weekly social call.
- Actively check in on other team members. Which feels silly to say, but the amount of times where I have seen teams only communicate during standup is also silly. Specifically juniors. If they are given a task after a little while check in with them how it is going and ask if they want to share their process. Basically how you probably in the office would walk past and also have a little conversation with them.
- Take time for questions from juniors and make it clear you will do so. Whenever you are in the office and they approach you for help it means you also often serve them on the spot. Yet online I have seen juniors being ghosted for a variety of reasons. At the very least make sure to respond to juniors with a "give me 5 minutes and I'll give you a call".
To be clear, I personally like working hybrid and I do think there are benefits to coming to office at least for one day per week (assuming it is coordinated and not a ghost town). But my main point is that juniors struggling due to remote work is often more a symptom of the company not really having a good training and coaching process/culture in place more than anything else.
Which I am not blaming on individual teams either. Training people is hard, people get bachelors degrees in education and then spend a lifetime getting better at educating. It's up to companies to educate their teams in this as well, offer the resources and have people on staff who solely focus on junior training.
> the Kashida section was contributed to this post from a talk in Arabic of Nawal Hadeed, which she translated and added to the post herself. Although I'm unsure of LLM usage in the translation process, looking at the original Arabic I felt some change in tone while editing the post. I could have either declined the translation and never have this documented, procrastinate in translating it myself (which has been ongoing for a while), or publish as it is. I found the last least damaging.
reply