Web development in 2023

Jamal

There are more fertile forums for a discussion like this, but hey, I like it here. Plus I have a feeling there are a few developers in the TPF membership.

I've been getting back into coding, trying to update my professional skills after many years of mostly updating and fixing something that was launched in 2015 (Note: I'm not referring to TPF, which is running on someone else's software). Now I've begun to look round at the landscape again, I see things have changed.

There seems to be a split between two entirely different philosophies of application engineering. On one side we have the single page application (SPA) JavaScript frameworks like React (plus Nextjs) and Vue. These things really got going around 10 years ago, moving away from the traditional website model or MPA (multi-page application). 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.

A whole ecosystem has developed around these frameworks (and Node), that makes using them much easier than it was back when I was building stuff. Examples of SPAs are Gmail, Netflix, Facebook, and Airbnb.

But the MPA model is still going strong. Where a server-side back-end written in Python, Ruby, PHP, or Golang is important (and this will continue to be the case for many or most complex projects), it's a lot of extra effort and maintenance headache to add another massive layer of complexity, not least because the front-end SPA that consumes the back-end's data has to be written in JavaScript/TypeScript. This is why Python, Ruby, and PHP frameworks remain popular. Examples of MPAs are Amazon and other eCommerce sites, Medium, TPF, and most websites.

And now we have things like HTMX—based on the Hypermedia Driven Application architecture (which, unlike SPAs, respects HTML)—and Hotwire/Turbo, so we can get MPAs (or at least, server-based applications) working fast and app-like from within a server-side framework without having to do lots of JavaScript.

Since things like HTMX now allow developers to build applications that feel like SPAs, I'm tempted to go down that route so I can stick primarily with Python, whose popularity is second only to JavaScript. However, JavaScript frameworks are very fashionable, and I've been trying them out. Great for small applications and sites, but a large system would be a whole other matter. That said, people have done it successfully.

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.

(Talking of AI, I've yet to try GitHub Copilot ("Your AI pair programmer"). Looks like it could save a lot of time.)

Generally, everything is in flux. I get the impression some projects are getting into trouble because of their eager embrace of frameworks that are immature and changing in fundamental ways year after year. I've read stories from teams that built applications with React only to scrap them and start again with a server framework.

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.

Jamal

And I don't know if it's me being old-fashioned, but there's something offensive about code like this:

export default function Blog({ posts }) {
    return (
        <Layout home>
            <Head>
                <title>{settings.siteTitle}</title>
            </Head>
            <section className={styles.articleList}>
                <ul className={styles.list}>
                    {posts.map((post, i) => (
                        <ArticleListItem post={post} key={i} />
                    ))}
                </ul>
            </section>
        </Layout>
    );
}

It's like doing classic ASP again.

baker

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. — Jamal

I think that before doing any of the demanding technical stuff (programming and whatever else is needed), one first needs to work out a philosophy of using technology to begin with.

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

Jamal

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

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?

Leontiskos

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 — Jamal

I used to write Ruby on Rails and Flash, among other things. This year I decided to try to brush up, so I did some things in Python and Django, with minor Javascript on the side. Then I thought it might be fun to chip away at a philosophy forum, so I grabbed Misago, which is written in Python (although the developer is going to move away from Python and towards a more Javascript-centric approach in the future). It was fine, but also underdeveloped. I looked at some other open source forum software, and eventually settled on NodeBB, which is written in NodeJS. I tinkered with that for awhile, got a working forum running with some nice bells and whistles, but had to leave it in limbo due to time constraints. After that I joined TPF.

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.

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. — Jamal

I also noticed that the asynchronous Javascript approaches have made strong advances, where it used to be more common to have scripting languages like Ruby or Python serve the backend. Supposedly speed is king, and Ruby and Python aren't fast enough (even though the initial page load of an SPA can be quite slow).

I'm really not caught up on all of the details, but it seems like the older approach catered to a low barrier to entry, with languages like Ruby and Python being easy to learn. Now I see more emphasis on speed, scalability, and monetization. With Rails you could get a website up and running very fast, but one-off websites seem to now lean towards website builders, a CMS, or a corporate hosted solution. Robust backends are probably going to become less common, although a lot of that probably depends on what happens with phone and tablet software.

Generally, everything is in flux. — Jamal

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.

Jamal

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. — Leontiskos

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.)

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

It's because they're good-quality languages, and because they're powerful. And if Rails and Django seem easy at first, it's because they're well-designed frameworks and have been around a long time. React, Next.js, and Ember can be confusing because their way of working is intrinsically messy. It's painfully obvious that they're immature—although things are much better than when I started using them in 2013. Serious business logic behind the API endpoints is more often implemented in Rails and Django than it is with React and Node.

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.

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

Yes, I started using static site generators about ten years ago, and these days they're the norm for developers' own websites. The challenge was always how to integrate them with content management, but this can be done now, and paid blogging platforms may go in that direction. If we could only get non-devs to start writing everything in Markdown instead of WYSIWYG, life would be better.

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. — Leontiskos

Indeed.

Jamal

Some interesting charts.

^{GitHub pull requests: https://madnight.github.io/githut/#/pull_requests/2023/2}

^{TIOBE Index: https://www.tiobe.com/tiobe-index/}

^{PYPL Index: https://pypl.github.io/PYPL.html}

^{Stack Overflow survey: https://survey.stackoverflow.co/2022/#programming-scripting-and-markup-languages}

^{Web frameworks: https://survey.stackoverflow.co/2022/#web-frameworks-and-technologies}

It's clear that JavaScript dominates in web development, as expected, but Python is so strong in general that it's obviously not going away (the rise of AI has given Python an extra boost too). And among the web frameworks Django is only just behind the front-enders and Microsoft.

Michael

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

Michael

↪Jamal

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. It certainly makes reactivity much easier.

Michael

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. — Jamal

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

Although I guess if you were just doing it in your spare time then it will take much longer.

Jamal

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

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.

I've been building a few things with NextJS for practice. I guess that fits in the stack roughly where Inertia does for you (I'd never heard of Intertia). Although--devil's advocate--don't you think the architecture is questionable when you're using not only two but three frameworks? (I'm not counting Tailwind since most projects use a CSS framework anyway)

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. — Michael

Yeh, I've been enjoying the JavaScript frameworks too, but I continue to question them.

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

Not everyone can be as awesome as you. :wink:

Jamal

Note that the question I asked ChatGPT was how long it would take to build a general purpose platform, not specifically for one group of users, so I think that's significant.

Michael

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. — Jamal

As someone who sucks at styling, Tailwind is a godsend. Perfect for component based frontends like React. I can see it being a pain in the ass if you just do raw HTML.

Also this is convincing.

Jamal

↪Michael

Good article. As I say, I do find the arguments convincing now. But I don’t think it’s essentially about which technologies you’re using, but rather the nature of the thing you’re building. Anyway, it’s not a huge deal for me, although I don’t know if I’ll ever get over my disgust at looking at all those long strings of atomic classes.

This is a pretty balanced article.

Jamal

Answers from ChatGPT 4 based on working on it full-time:

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.

Then I said what about security:

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.

(Come on Plush, give us Markdown support please. EDIT: Plush just confirmed to me that they will only ever support BBCode, not Markdown :angry: )

Jamal

I just realized it might be assuming I had no experience in web development, so I asked for a new estimate to take into account my experience:

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

Leontiskos

↪Jamal

- Wonderful data here, thank you. This is basically why I chose to focus on Python/Django with Javascript on the side, but I was using secondary sources and not survey data. The GitHut pull requests reflect the exact timeframe I was away from web development.

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: — Jamal

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 <this post> 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.

NodeBB's architecture can support long form discussion, and there is also a prebuilt theme that matches such a use case (Lavender). I also like NodeBB because it is modular (utilizing themes and plugins) and there are lots of different people working on it and contributing. It allows a lot of customization without having to reinvent the wheel. In essence, I settled on NodeBB because it is open source, it is well-developed (commercially backed), it has a strong community, and it is compatible with long form discussion. (I am also on a budget, and I could run a small forum on Misago or NodeBB for $10 a month.)

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.) — Jamal

Okay, interesting! That makes a lot of sense, and it is encouraging to me. I suppose I was extrapolating from the idea that frameworks like Next.js could create a uniform and apparently simple Javascript landscape (with the addition of Rust). I was assuming that the creation of a less complex and less layered web approach might take hold, and that even if architectural simplicity leads to certain difficulties (such as the fact that a language like Rust is unwieldy when compared with Python), these could be overcome by tools that abstract away some of the low-level idiosyncrasies for less advanced programmers, as AI is already beginning to do. But my thoughts here were largely conjectural, and I hope I am wrong. In any case, you are certainly right that a more robust backend will always be required for the most important and ambitious projects.

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. — Jamal

Good points. You are correcting my premature thinking in helpful ways.

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.

SophistiCat

Not a web developer (or a pro developer) here, so don't have anything to contribute. I have a slightly off topic question though if you don't mind. I've been doing a bit of coding for study, work, or small personal projects for about as long as Python has been around, but I've always been prejudiced against it. 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? (I also dislike JavaScript, but in that at least I don't seem to be alone.)

Jamal

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 <this post> 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. — Leontiskos

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”.

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. — Leontiskos

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.

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. — Leontiskos

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.

Jamal

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

I think it’s great. Most code is indented anyway, even when what you actually need is curly braces. Python enforces it so it’s all you need, and readability is then assured—and improved, in my opinion. It’s never been an issue. I’ve hardly ever had problems with it when working with other people’s code, for example. Occasionally you get an ‘IndentationError’ but it’s no big deal.

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

I’ve only used it for web development, associated modules, and scripting, but it’s a true general purpose language and designed as such. It’s used to build many kinds of applications, for machine learning, data science, etc. Whether there are advantages beyond the obvious ease of use, flexibility, and readability, I don’t know. I don’t claim it could replace all the Java in the world. I like the way it looks and it’s a lot of fun to use.

Leontiskos

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”. — Jamal

Haha - yes, I agree with all of that.

I have three instances of NodeBB running locally, one on Postgres. 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.

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. — Jamal

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 did get the vague sense that NodeBB was more open to accommodating long-form forums, perhaps because they claim to be the successor to phpBB and therefore cannot totally abandon that format. But this is a rather whimsical intuition. I also wanted the "discussion" pages to have a single-column, no frills UI that was deeply content focused, and the NodeBB Lavender theme fit that bill. I actually style my TPF client that way.

I had a lot of picky details that I wanted, and NodeBB was able to fulfill almost all of them. For example, I can set the number of upvotes a user is allowed daily, and, separately, downvotes. I can set this according to the user's post count or status if I want. I can ditch the reputation system. I can place limitations on users' ability to post (e.g. can't post twice within 10 minutes). I can have a sub-forum only visible to paying users, where the merits of internal features can be debated. Maybe Discourse can do all of that too. I am sure that larger features, such as moderation queues for new users and forward-links to replies, are available on both platforms. I will say that the NodeBB community is remarkably active and responsive (but this may also be true of the Discourse community).

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. — Jamal

That's fair. This could be a cool way to get back into it. I do advise against starting from scratch. 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.

When I joined TPF I was thinking about these questions regarding forum software way too much, but now I'm wishing I had taken more notes. Granted, I was mostly comparing NodeBB, Misago, Plush, Xenforo, and phpBB. My knowledge of Discourse is scant.

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.

Bob Ross

↪Jamal

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

Personally, for web development, I am not a big fan of using (what was traditionally) client-side languages as server-side (such as javascript with Express.js and Node.js for servers) nor newer languages (like Python with python flask) as they are slower and tend to have been been pentested much less than other, more traditional, server-side languages (like Java, PHP, etc.). The tradeoff is that they are easier to program in and they 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.

PHP is my favorite server-side language, as it has a long track record, great documentation, its dynamically typed but gives the option of statically typing (with type naming), and is fast.

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?

Wayfarer

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

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)?

Jamal

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

I agree. In my original post I was examining what I see as two competing paradigms of web development today, but it's no doubt true that solutions lie in between.

newer languages (like Python with python flask) — Bob Ross

they are slower and tend to have been been pentested — Bob Ross

are the fad — Bob Ross

Flask is older than Laravel, and Python is older than PHP. Python's most popular framework, Django, was released in 2003, before all the PHP frameworks that are still going (I think, pretty much). 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). Generally, your Python/Javascript vs. PHP/Java dualism doesn't reflect history or reality very well.

If you love PHP, cool, I have nothing against it (except bad experiences and personal taste). I'm not interested in cheerleading for anything or in anyone else's cheerleading–but let's get the facts straight.

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. — Bob Ross

I won't argue with any of that.

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. — Bob Ross

Yes, and from a development perspective the front end frameworks can be so bloated, it takes discipline and coordination to keep things under control. But when the aim is a speedy responsive user experience, and given that browsers are powerful enough for the job, SPAs can be a good choice. But I see where you're coming from and as I said in the OP, I believe it's becoming possible now to achieve the superior user experience from within server frameworks like Laravel and Django, but without adding a whole Javascript framework to the mix.

So despite your odd view of Python, we kind of agree.

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. — Bob Ross

Thanks Bob.

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

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:

Jamal

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)? — Wayfarer

I don't know. Last I checked, Plush documentation was virtually non-existent. You must be right though.

Wayfarer

↪Jamal

I looked up the documentation on BBCode, it's pretty basic, but I think Plush only implements a minimal set of tags. No worries, I was just wondering if there might be anything I could add to the User Tips and Tricks in that regard, but probably not.

Jamal

↪Wayfarer

I know there are some things that don't have associated text box button icons, like ^sup for superscript.

Jamal

↪Leontiskos

:up:

Will respond tomorrow.

Leontiskos

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)? — Wayfarer

Yes, but this is not so unusual. I have never used a BBCode editor that supports all possible BBCode tags.

Bob Ross

↪Jamal

Hello Jamal,

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

Fair enough.

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 still think Python isn’t the greatest language for a server-side language, but we can just agree to disagree on that.

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)

I am not familiar with Django (unfortunately), but I see PHP progress as providing ample evidence of it being thoroughly abused and tested by the community. I doubt, although I haven’t looked yet, that Django doesn’t or hasn’t fallen prey to most (if not all) of what PHP has. If Django has been a stable web server framework since 2000s (with its fair share of CVEs and community testing), then I think it meets my criteria of having a good track record; although I wouldn’t use it since it runs Python as its server-side language (:

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

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:

Interesting!

Jamal

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. — Leontiskos

Great, I didn't realize.

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. — Leontiskos

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).

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. — Leontiskos

I know what you mean. At first when you think of how to build a forum it seems easy, but there's a lot more to it.

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. — Leontiskos

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.

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. — Leontiskos

:up:

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).

Web development in 2023

Welcome to The Philosophy Forum!

Categories

More Discussions