Web development in 2023

export default function Blog({ posts }) {

    return (

        

            

                

            

            


                


                    {posts.map((post, i) => (

                        

                    ))}

                


            


        

    );

}

but even if you have no idea what I've just been talking about, any thoughts about the state of web applications and websites today is welcome.

See Cal Newport's Digital Minimalism for more on this.

Like Michael, I've toyed with the idea of building forum software for TPF so I can bring the data and codebase under our control

I want your thoughts. Primarily I want to know about the experiences of developers, but even if you have no idea what I've just been talking about, any thoughts about the state of web applications and websites today is welcome.

Generally, everything is in flux.

Instead of building a forum software from scratch, why not leverage and customize an open source option? Vanilla/Plush seems decent for your purposes, but you could self-host for much cheaper if you are able to provide the technical labor. NodeBB, Vanilla, Misago, Flarum, and Discourse are some of the open source options I looked at. Using NodeBB with the Lavender theme seemed like the best option for a philosophy forum, although Misago is also very clean.

the older approach catered to a low barrier to entry, with languages like Ruby and Python being easy to learn

Yes, and I think this is why static HTML/Javascript is making a small comeback.

There is a greater cognizance of maintenance and updating costs. In general it seems that the magnanimity of the tech boom is behind us. Cost and monetization loom larger than they once did when we were dazzled by the novelty and the low-cost-relative-to-the-past.

Like Michael, I've toyed with the idea of building forum software for TPF so I can bring the data and codebase under our control. I asked ChatGPT how long it would take and it gave me two answers: either 6 months to a year, or 18 months to 3 years. The latter estimate is more realistic for a full-featured (and extra-featured) forum platform. I can't dedicate that much time to it unfortunately.

I've recently been using Laravel with Inertia, React, and Tailwind for the frontend. Works really well.

I used to think that. I always thought that HTML should just be done in HTML, not JavaScript. But then I actually tried React and Vue and quite like it.

That strikes me as an overestimate. I've built business CRMs used by a FTSE 100 company in a few months.

Cool. I used to be dead against non-semantic CSS like Tailwind, but the arguments in its favour are persuasive. I think it depends what you're building. If it's content-focused, semantic makes sense, but if it's highly interactive, things like Tailwind look good.

Building a forum with a feature set similar to Discourse from scratch, especially when learning React and Next.js concurrently, is a substantial endeavor. Here's a broad estimation of the time it might take based on various stages of development:

1. **Learning Basics (React and Next.js)**:
- **Duration**: 2-4 weeks.
- This phase includes understanding the fundamental concepts, building small projects, and becoming comfortable with the development environment.

2. **Design and Architecture Planning**:
- **Duration**: 1-3 weeks.
- Outline the features you want to implement. Decide on database structures, authentication mechanisms, state management strategies, and other foundational elements.

3. **Core Features (MVP - Minimum Viable Product)**:
- **Threads and Posts**: 2-3 weeks.
- **User Registration & Authentication**: 2 weeks.
- **User Profiles**: 1 week.
- **Basic Admin Tools (user management, basic moderation)**: 2-3 weeks.
- **Duration**: 7-9 weeks for a basic MVP.

4. **Advanced Features**:
- **Advanced Moderation Tools (post edits history, user warnings)**: 2 weeks.
- **Private Messaging**: 2-3 weeks.
- **Search Functionality**: 2 weeks.
- **Categories & Tags**: 2 weeks.
- **Notifications**: 2 weeks.
- **Duration**: 8-11 weeks.

5. **Additional Features (Common in Discourse and Similar Platforms)**:
- **Badges & User Levels**: 2 weeks.
- **Bookmarks**: 1 week.
- **Polls**: 1-2 weeks.
- **Attachments & Media Handling**: 2 weeks.
- **Duration**: 6-8 weeks.

6. **Testing, Bug Fixing, and Refinement**:
- **Duration**: 4-8 weeks.
- This is crucial. As you develop, you'll discover edge cases, usability issues, and bugs that need addressing.

7. **Data Migration and Integration**:
- **Duration**: 2-4 weeks.
- Migrating from an existing platform can present challenges, especially if the data structures differ.

8. **Deployment and Scaling**:
- **Duration**: 2-4 weeks.
- This phase includes setting up servers, handling security considerations, ensuring the platform scales with user growth, and other deployment-related tasks.

Given these broad estimations, you're looking at approximately **32-61 weeks (8-15 months)** to develop a full-fledged forum application with a feature set akin to Discourse. This time frame assumes you're working on it full-time. If it's a side project, the duration will extend accordingly.

It's crucial to note that these estimates are quite generic and can vary based on individual speed, unforeseen challenges, feature complexities, and other factors. Some developers might move faster, while others might need more time, especially when dealing with the intricacies of a forum application.

Absolutely, security is paramount when developing any web application, especially something as user-focused as a discussion forum. Neglecting security can lead to data breaches, unauthorized access, and many other serious issues. Let's break down the key security considerations and their potential time implications:

1. **Authentication**:
- Implementing secure login mechanisms is essential. Consider using established libraries or services like OAuth or Auth0.
- **Duration**: 1-2 weeks (on top of basic user registration & authentication).

2. **Authorization**:
- Ensure that users can only perform actions they're permitted to do (e.g., only admins can delete any post).
- **Duration**: 1-2 weeks.

3. **Data Validation and Sanitization**:
- Protect against SQL injections, script injections, etc. by validating and sanitizing user input.
- **Duration**: 2-3 weeks.

4. **Secure Data Transmission**:
- Implement HTTPS across your forum to encrypt data in transit.
- **Duration**: Less than a week (but requires ongoing monitoring).

5. **Data Encryption**:
- Passwords and sensitive data should be encrypted before being stored.
- **Duration**: 1 week.

6. **Session Management**:
- Implement secure session handling to prevent session hijacking or fixation.
- **Duration**: 1-2 weeks.

7. **Rate Limiting**:
- Implement rate limiting to prevent abuse (e.g., rapid-fire login attempts or spammy post creation).
- **Duration**: 1 week.

8. **Content Security Policy (CSP)**:
- Define what resources can be loaded to protect against cross-site scripting (XSS) attacks.
- **Duration**: 1 week.

9. **Cross-Site Request Forgery (CSRF) Protection**:
- Protect your forum from CSRF attacks by implementing anti-CSRF tokens.
- **Duration**: 1 week.

10. **Regular Security Audits & Updates**:
- Tools like Dependabot can be used to stay updated with the latest security patches for your dependencies.
- **Duration**: Ongoing, but setting up monitoring and automated updates might take a day or two.

11. **Backup and Recovery**:
- Regularly back up the forum data and have a recovery plan in place for emergencies.
- **Duration**: 1-2 weeks.

Adding up these security-specific durations, you're looking at an additional **12-19 weeks** dedicated solely to security. These estimates are, again, very broad. Some tasks may take less time if you're using specific frameworks or libraries that handle them out-of-the-box. However, security is not a one-time task. It requires ongoing attention, regular updates, and occasional audits to ensure that the platform remains secure as threats evolve.

Incorporating these security considerations into the earlier timeline, you're looking at a more comprehensive project duration of approximately **44-80 weeks (11-20 months)** if undertaken full-time.

Taking these adjustments into account, the comprehensive project duration might come down to roughly 25-50 weeks (6-12 months) if undertaken full-time.

Yes, it’s the best option. I was only toying with the idea of building my own from scratch because I was getting back into development and wanted a meaty project. NodeBB and Discourse are the two I like the look of most. Vanilla is good too, but I don’t want to get involved with anything PHP (I know everyone says it’s great these days but my experience was traumatic). I’d never heard of Misago. Looks great, and codewise I like it better than NodeBB and Discourse, mainly because I like the combination of Python and JavaScript. I shall try it. Thanks for the tip :up:

On the state of things now and the future, I think you're both right and wrong. It's true that the front-end frameworks are the most visible and fashionable area of web development now—even non-developers I know have heard of React—but (a) people are realizing that on big projects where there's a lot of data involved, frameworks like Rails and Django perform better and are easier to maintain, (b) many are saying that things are moving back to the server frameworks now that the speedy front-end user experience of SPAs can be achieved, and with much less hassle, and (c) most front-end applications depend on an API built with something like Django anyway, so even when React is being used, something like Django is being used too. Some would say that this is for legacy reasons, but I actually think it's because Python is so strong right now, and getting stronger. Even if Django falls out of favour, other Python frameworks like FastAPI and Flask will take over. It's a lively area, though less visible than the front-end stuff.

(In fact, you could say that the existence of the big front-end frameworks is a consequence of legacy as much or more than the continuing presence of Django and Rails: browsers only understand JavaScript and there's no way out of that right now. In software terms, browsers are old technology, in which backwards-compatibility is a big issue.)

And the more that asynchronous JavaScript becomes an integral part of Rails and Django development—but without using big front-end frameworks—the more I expect to see them thrive. So I don't agree that robust back-ends are on the way out except where they were never really needed.

What we see is at the level of small-to-medium websites, the server-side frameworks have lost out, and that's probably as it should be. At this level, we have (a) static site generators or primarily static sites and immediate interactivity with asynchronous CRUD to a backend API, and (b) as you mentioned, website builders like Squarespace and Wix.

That would definitely be a meaty project, but rewarding if it could be done. Misago is the Python frontrunner, which is why it was my first choice. Unfortunately it is provided by a single developer who works on it in his spare time, but he is talented and I am sure he would appreciate help (see regarding the current plans for Misago). NodeBB and Discourse have multiple full-time developers along with the attached commercial interests, and therefore possess more stability. I agree regarding Vanilla and PHP.

A crucial factor in my considerations was long form vs short form discussion formats, as a philosophy forum requires a more long form format. A lot of the newer, asynchronous forum frameworks cater to short form discussion and phones/tablets (Discourse does not even support pagination). They are becoming a blend of forums and instant messaging, running away from phpBB in a way that strikes me as both good and bad. If the architecture is suitable one could restyle them for long form purposes, but I am not great with CSS so I wanted something compatible with long form discussion right out of the box. Plush is good on this score, and Misago looks and feels a lot like Plush.

Thanks for your thoughts. I didn't know you were a developer. I don't think I could call myself a developer at this point, although I could get back into it fairly easily.

Its use of indentation for syntax seems like a monumentally bad idea. What do you have to say for that?

And are there advantages to Python beyond its use in server scripting?

It’s unfortunate that Misago isn’t more active. As things stand, I suppose it would have to be NodeBB or Discourse. I’ll install them both and try them out. I tried Discourse a while ago and quite liked it, but I didn’t pursue it. The big headache in either case will be migrating the data. My familiarity is with relational databases so I’d probably be more at home with Discourse, which uses PostgreSQL. What is certain is that neither has a big button that says “Migrate from PlushForums”.

I’m curious: what is it about, say, Discourse, that steers things away from long-form discussion? From what I could tell when I tried it, navigating a discussion was easier than on other platforms, and it made composing long posts much more pleasurable than here (same with NodeBB: full-screen distraction-free editing, for example). Maybe I’m missing the obvious, but pagination isn’t a requirement for long-form is it? Although it occurs to me that pagination is better for SEO.

I’m really just going by intuition and doing my usual contrarian thing. Sometimes it leads me in good directions. I haven’t really been a developer for years, since I was a bit stuck in maintenance with the last project I was involved with. But yeh, I’m getting back into it nicely.

Plush just confirmed to me that they will only ever support BBCode, not Markdown

Firstly, there is no "the best" framework or languages for programming: it depends entirely on what the project is that one is developing.

newer languages (like Python with python flask)

they are slower and tend to have been been pentested

are the fad

My philosophical approach to web projects is minimalism (viz., keep it simple stupid), compartmentalization (viz., always, always, always separate code so that it is modularized: cleaner, more scalable, easier to read, and takes up less storage), documentation (viz., always document what the heck this thing does, and pick languages and frameworks that are well-supported: easier to get people to work on the project, easier to teach them, and easier on you to develop with it), and secure (viz., don't pick the newest language, framework, or library on the block, it takes time for ethical hackers to find vulnerabilities); so I love minimalistic MVC (model-view-controller) frameworks with amazing documentation that utilize very well-known and well-established server-side languages, such as Laravel.

With regards to libraries and frameworks like React and Angular, it is important to know that it all runs client-side, which adds runtime on the user's browser. Although it is beneficial to run some stuff on the client-side, to save server-side runtime, it is important not to over-bloat the client side; which I worry happens with those kinds of libraries and frameworks for a lot of projects who picked them just because they are in style right now. I would rather keep it simple, and use pre-compiled TypeScript for client-side operations, and keep it absolutely minimal to save client-side runtime.

If you are trying to revamp this website, then please do not hesitate to contact me if you need any help; as I would not mind helping out with a site like this that I enjoy using.

What are you guys currently using for the client-side, server-side, query, and style-sheet languages?

Would I be correct in saying that Plush only supports a sub-set of BBCode, i.e. not all the tags are implemented (e.g. tables)?

Would I be correct in saying that Plush only supports a sub-set of BBCode, i.e. not all the tags are implemented (e.g. tables)?

Flask is older than Laravel, and Python is older than PHP.

Django and Python have a very strong reputation for security; PHP does not (an unfortunate legacy of wilder times, no doubt, which the language has put behind it)

As mentioned in the OP and the ensuing discussion, I'm not hosting TPF myself and I don't have any control of the code. It's hosted by PlushForums, built on Vanilla, which you'll be happy to know is written in PHP :grin:

NodeBB was originally built with MongoDB, but it runs on Postgres just fine. That's what I deployed it on. I think that compatibility was added sometime in v2.

The simple answer is that I wanted pagination, even prescinding from its SEO favorability. Infinite scroll on a long-form philosophy forum didn't seem right to me. NodeBB offers both, and individual users can even change the setting on the client side. So I'm not a great person to ask about Discourse, as I never installed it. I have it on good authority that it is a bit harder to install and consumes more resources, but those aren't deal breakers. Both platforms are robust, with more to offer than Plush. Granted, I have come to appreciate the simplicity and distraction-less nature of Plush.

I had that idea until I installed Misago and started digging into the Github history. There are many more features than I had anticipated, especially when it comes to security, moderation, IP tracking, etc.—but I think ChatGPT has already given you a good sense of what is involved.

Also, after I joined I realized more concretely that TPF has one thing no other philosophy forum has, and that no forum software can create: a healthy community of users. Without that, it's all just window dressing.

Whatever you decide, I think a forum software would benefit from having a philosophical client. The things you guys have suggested and requested from Plush seem spot-on, and are much more thoughtful than the short-sighted requests I have seen from the business world.

From my experience, I have seen python being used as a server-side language only relatively recently (but perhaps I just haven’t been around the right groups of people who love Python). Originally, people (as far as I know) used Java, C#, and PHP. If someone was running a website, it was most likely PHP or Java (and not Python). If python was used for web servers before PHP/Java (like Django) in a stable fashion, then I am simply unaware of it and will have to read up on that.

I will have to checkout Django sometime though. Is it minimalistic or bloated?

With SPAs, different views are rendered (and actions completed) in the browser without loading a new page or refreshing, using JavaScript to invisibly communicate with the server. Often, all the necessary HTML, JavaScript, and stuff are downloaded once, when you log in.

I abhorred these things when they first came out. If your internet is not good or perhaps is throttled due to reaching an allotted usage level, nothing would ever load and worse never told you it didn't. They seemed to have improved it by forcing a manual redirect/better fail-safes in more robust frameworks but there was nothing like clicking a link or performing an action and the browser itself telling you "hey it failed" right when it did so you knew to refresh or try again later. Just my 2 cents.

Often, all the necessary HTML, JavaScript, and stuff are downloaded once, when you log in.

Which websites for example offer this truly "one page" browsing in entirety?

Where you visit example.com and every action or section never changes the URL regardless of the intricacy or specificity of the action?

https://mail.google.com/

Gmail slack Trello Netflix and grammarly

Well sure, but what is an email web client but a collection of notes, albeit most sent by others and to and fro. If you do anything but opening a note or adding to it (responding to an e-mail) say, changing account settings it does a full redirect to a different URL.

There were three things you said or implied that I took objection to: (1) that Python is a new language or at least a new language for web development

(2) that Python and/or Python frameworks have not been properly tested and are unstable or insecure

(3) that PHP belongs in the same language ballpark as Java.

What I did not claim is that Python was used in web development before PHP was; as far as I know the Django guys were the first to use it to build websites. But twenty years (since Django was released) is a decent length of time, and its record is very good. And yes, PHP has always been more popular as a way of building websites.

Java and Python are general purpose languages that can do anything, and on the other side you have PHP and JavaScript, which are just scripting languages

It's a difficult question to answer without knowing what you mean, but depending on which way you look at it, it's both. Flask, on the other hand, is certainly minimalist. But Django adheres strongly to conventions and paradigms, such as DRY, and the separation of concerns of MVC (although they use different nomenclature and slightly different structure, namely model-view-template), so it's a good coding experience. Things never got messy for me in Django, as they definitely did when I was building in JavaScript frameworks.

But since you don't like Python, there's little point in wasting your time on it.

So I say, enjoy your PHP :cool:

Gmail settings will not load a new page.

Also remember you're describing AJAX deep down at the end of the day

Java and Python are general purpose languages that can do anything, and on the other side you have PHP and JavaScript, which are just scripting languages

I get what you mean, but I wouldn’t classify them this way.

It is not that I don’t like Python, but, rather, I don’t think it is a good server-side language for web development

I like magic most when there's a clear way to demystify what's actually happening underneath the hood. The biggest problem with magic that you can't demystify is that it's hard to predict what other kinds of things you can and can't do with it, you know?

I've got a bug related to sessions and it's so hard to find out what's going on there!

Aside from wanting to control the data and code, I'd actually be perfectly satisfied with the way Plush works with just a few changes, like better tools for moderation, "zen mode" post composing, Markdown support, dark mode, and ignore lists.

(I know that for dark mode I could just use Stylebot as you suggest, but this is about built-in functionality; as admin I need to see what most people see).

This is what makes a decision to move to another platform a big and difficult one.

Incidentally, it always sounds odd to me when I see people saying that discussion forums are dead (because Reddit, social media, and Discord). I guess my experience is not normal.

Although the Plush folks assure me that PlushForums will be maintained for the foreseeable future, they don't seem very interested in adding new features, perhaps because they've been putting most of their efforts into their new platform https://insta.forum/ (totally moving away from long-form, so not suitable for us).

In my world the framework that's famous for hidden magic is Rails, whose principle is "convention over configuration". On the other side, the Python folks say "explicit is better than implicit." The two are definitely in conflict.

Often, all the necessary HTML, JavaScript, and stuff are downloaded once, when you log in.

Is this maybe the reason why some sites are quite slow in loading? I guess they must be the ones with a huge content. Do you know any of them --that use this method-- so I can check if this is true?

If you mean the ones that load everything up-front, rather than those that use code splitting, I’m not sure.

Can I download my data?
Yes. You own your own data. A copy of your files (including uploads and avatars) and databases (full dumps) can be downloaded from the Backups menu of the Discourse admin panel at any time.

Plush seems like it's working pretty well. I really like the feature where I can click on the title bar and return to the post I just quoted. My concern is that Plush seems near the end of its lifecycle. If you look at the second half of my post , you can see a number of the things Plush hasn't managed, despite requests. Most of that stuff has been standard for years now, along with ignore lists and strong moderation tools. If Plush won't budge on those things, then I have to wonder if they are in maintenance mode, nearing their expiration date. NodeBB and Discourse don't show evidence of this lifecycle issue.

I think your experience is not normal because your moderation is not normal. I think that's why your forum is so much better than the alternatives: you have superior moderation and your moderators have a good grasp of philosophy.

P.S. One significant feature that NodeBB hasn't yet managed is composer keyboard shortcuts. For example, Ctrl-i won't give you italics.

As of today I’ve got Discourse running now on a host that does managed Discourse hosting. Some people on meta.discourse.org say they’re very reliable. I think this is the way to go. I don’t want to deal with hosting. These folks take care of backups, software updates, and all the rest, while I have the power and control of the Discourse admin (e.g.,

Yep, and Discourse would take care of most of the feature requests, I’m guessing?

It's kind of a small thing, but I use that all the time, including here.

I actually set one up there a few years ago and didn’t pursue it just because I wasn’t in the mood or I didn’t want to face the data issue. This time I hope to see it through, some time in the next weeks or months. In the meanwhile I’ll invite testers once I’ve fine-tuned it (this week probably but I don’t know when I’ll get around to it).

So on NodeBB a lot of the customization comes through themes and plugins, which can be substituted, created, shared, etc. But the access to this customization is somewhat host-dependent (and this is especially true when it comes to hosts that do not allow command line SSH server access). If a similar thing holds with Discourse, then I would suggest double-checking that the hosting company allows that level of deeper customization (and ideally command line access). You could easily leverage the deeper level of customization if you have need in the future, given the many developers among your users.

This sounds great. I am of course willing to help as I am able, although I should say that this is precisely the time of the year that gets busy for me.

The host says they'll install any plugin we want, including any we write specifically for TPF.

Thanks, your guidance will be valuable since you have all this forum configuration experience, but I won't burden you too much.

Yep, and Discourse would take care of most of the feature requests, I’m guessing?

I’ll have to read the discussions that were had here about it to remind myself of how it works on Plush and what people didn’t like about it.

SPAs don't require Ajax.

You load every single item (thousands), image link, and description (often lengthy) when someone visits your homepage? That doesn't seem efficient to me. I suppose it simply loads the blank "default item" page and clicking the item individually loads its information? That would still require every single item in inventory's ID, picture, title, and usually price to be loaded from the first homepage visit. That seems a bit much.

But for anything useful like a public forum or guestbook, or say billing or payment application where an action could have been made from another avenue ie. by phone and needs to be updated, it really ought to communicate with the server, wouldn't you say?

var me = document.getElementById('Outlander');



me.onclick = function()

{

  alert( 'But what about someone who does not have Javascript functionality either inherently or disabled for security reasons?' );



  // just for fun

  for ( var i = 0; i < 2; i++ )

  {

    i--; alert( 'Ye cannot escape! Mwahaha!' );

    // or if you really want to get twisted

    // window.open( 'http://www.adultwebsite.com', _blank );

  }



}

What does Cal say, and why do you think it's important? Is it something like, stop scrolling through Instagram and go for a walk instead?

Digital minimalism is a philosophy that helps you question what digital communication tools (and behaviors surrounding these tools) add the most value to your life. It is motivated by the belief that intentionally and aggressively clearing away low-value digital noise, and optimizing your use of the tools that really matter, can significantly improve your life.
/.../
The bottom line of this general thinking is that a simple, carefully curated, minimalist digital life is not a rejection of technology or a reactionary act of skepticism; it is, by contrast, an embrace of the immense value these new tools can offer…if we’re willing to do the hard work of figuring out how to best leverage them on behalf of the things we truly care about.

https://calnewport.com/on-digital-minimalism/

You did say any thoughts on the state of web applications and websites are welcome.

Perhaps a separate thread is in order.

I see you're using Typescript.

By the way, amongst the front-end frameworks, I've found Svelte to be the most enjoyable to work with.

I'm also in the process of building a PHP framework, inspired by Laravel but much smaller and faster.

my colleague is suggesting htmx for future projects so that's what I've been doing recently and what inspired me to make this.

It's a work in progress so not yet open source but parts of it are public anyway so check it out if you're interested: https://github.com/wtframework

I'm particularly proud of the SQL statement builder (https://github.com/wtframework/sql). My intention is to allow for the full spec. Just need to finish off some CREATE and ALTER stuff (mostly to do with partitions).

the SQL stuff is a bit yikes to me.

$framework = new MyFramework; $framework->function( $some, $variables, $here );

function __construct() { $this->appName = strtolower( parent::class ); $this->sectionName = strtolower( static::class ); }

Hopefully things haven't changed too much...

function FormHandler( $prefill = array() ) { /* */ }

I had to Google the "readonly" stipulation. What realistic (or even atypical) case scenarios can you provide that warrants its explicit use?

class Person

{

  public function __construct(public readonly string $name) {}

}



$person = new Person('Michael');



echo $person->name;

class Person

{

  protected $name;

  public function __construct($name)

  {

    $this-name = $name;

  }

  public function getName()

  {

    return $this->name;

  }

}



$person = new Person('Michael');



echo $person->getName();

I'd much rather a default function-level based "error handling" (ie. not integer detected therefore, perform this) than a top level PHP error that breaks whatever the user is doing (and often the site or at least the specific action page in the process).

Strict typing ensures that these mistakes are picked up in development.

class Person

{

  protected $name;

  public function __construct($name)

  {

    $this-name = $name;

  }

  public function getName()

  {

    return $this->name;

  }

}



$person = new Person('Michael');



echo $person->getName()

;

class Person

{

    function __construct( $name ) { $this->name = $name; }

}



$person = new Person( 'Michael' );



echo $person->name;

$person->name = 'Mike';

class Person

{

  public readonly string $initials;

  public function __construct(

    public readonly string $first_name,

    public readonly string $surname,

  )

  {

    $this->initials = substr($first_name, 0, 1) . substr($surname, 0, 1);

  }

}



$person = new Person('John Smith');



echo $person->initials;

Often times you don't want that which is why such properties are usually protected or private.

$importantInfo = $twilio->importantInfo;

$twilio->importantInfo = 'something that breaks the script';

If they choose to break the code, even unintentionally, perhaps they shouldn't even be coding in the first place.

That's the entire purpose of things like public, protected, private, readonly, final, typing, interfaces, abstract, etc; to ensure that developers do things properly.

Being able to see at a glance 'protected "name"' immediately tells them that they're not supposed to do '$class->name = 'foo'''.

$class->_reservedVariable;

$class->wtf_variable;

Instead use a prefix so it would be

$_name

That used to be how things were done, but then PHP introduced "protected" and "private" visibility precisely so that we didn't have to do this.

So it's not like it actually frees up the use of the literal verbose name of the variable itself. It just makes it so "Ok now I have to use use '$name2' or '$variable2' instead of what comes firsthand in mind." as far as secondhand development/utilization of a framework goes.

No, it means you're not allowed to change the name.