Zust.ai

zustai

11 Best AI Chat Tools for Developers in 2024

Introduction Developing a real-time chat application involves more than just basic messaging. In this tutorial, we’ll explore how to build a fully responsive chat app from scratch using modern web technologies. This app includes essential features like group chats, file uploads, and real-time communication, making it an excellent project for anyone interested in full-stack development. Key Features of Our Chat Application Here’s a breakdown of the key features and technologies that power our chat app: Frontend (React) UI Components: ShadCN for intuitive, modular components.
Styling: Tailwind CSS ensures a modern, responsive design.
Responsiveness: Adaptable for both mobile and desktop devices. Backend (Node.js and Express) Data Storage: MongoDB, optimized for handling user data and messages.
Authentication: JWT for secure, token-based authentication.
Real-Time Communication: Socket.io for instant messaging functionality. Additional Features File Handling: Multer is used to handle file uploads and storage.
State Management: Zustand for managing user sessions and chat states.
API Calls: Axios for efficient API communication. Building the Frontend In this section, guide your readers through setting up a React app and installing dependencies like ShadCN, Tailwind CSS, and Zustand. Setting Up the React App: Begin by initializing a React app and setting up the basic folder structure.


Adding Responsiveness with Tailwind CSS: Explain how to install and configure Tailwind CSS for styling and responsiveness.


Implementing State Management with Zustand: Walk through how Zustand can manage chat states, making the app feel responsive and smooth.


Integrating Sockets for Real-Time Updates: Show how to set up Socket.io on the frontend to enable real-time communication between users. Backend Implementation This section covers setting up a Node.js and Express server with MongoDB as the database and Socket.io for real-time messaging. Setting Up the Express Server: Go over the initial setup, including installing dependencies, configuring routes, and connecting to MongoDB.


Integrating JWT for Authentication: Explain how to use JWT for user authentication, including token creation and validation.


Handling File Uploads with Multer: Demonstrate how to integrate Multer to handle image and file uploads, including setting up file storage and managing uploads.


Enabling Real-Time Messaging with Socket.io: Detail how Socket.io powers instant communication, allowing users to send and receive messages in real-time. Check out the full 10+ Hour Video on my YouTube channel. For more such Full Stack Apps, subscribe to my YouTube channel. https://www.youtube.com/watch?v=W3sOezpkGWI&embedable=true Introduction Introduction Developing a real-time chat application involves more than just basic messaging. In this tutorial, we’ll explore how to build a fully responsive chat app from scratch using modern web technologies. This app includes essential features like group chats, file uploads, and real-time communication, making it an excellent project for anyone interested in full-stack development. Key Features of Our Chat Application Key Features of Our Chat Application Here’s a breakdown of the key features and technologies that power our chat app: Frontend (React) UI Components: ShadCN for intuitive, modular components. Styling: Tailwind CSS ensures a modern, responsive design. Responsiveness: Adaptable for both mobile and desktop devices. UI Components : ShadCN for intuitive, modular components. UI Components Styling : Tailwind CSS ensures a modern, responsive design. Styling Responsiveness : Adaptable for both mobile and desktop devices. Responsiveness Backend (Node.js and Express) Data Storage: MongoDB, optimized for handling user data and messages. Authentication: JWT for secure, token-based authentication. Real-Time Communication: Socket.io for instant messaging functionality. Data Storage : MongoDB, optimized for handling user data and messages. Data Storage Authentication : JWT for secure, token-based authentication. Authentication Real-Time Communication : Socket.io for instant messaging functionality. Real-Time Communication Socket.io Additional Features File Handling: Multer is used to handle file uploads and storage. State Management: Zustand for managing user sessions and chat states. API Calls: Axios for efficient API communication. File Handling : Multer is used to handle file uploads and storage. File Handling State Management : Zustand for managing user sessions and chat states. State Management API Calls : Axios for efficient API communication. API Calls Building the Frontend Building the Frontend In this section, guide your readers through setting up a React app and installing dependencies like ShadCN, Tailwind CSS, and Zustand. Setting Up the React App: Begin by initializing a React app and setting up the basic folder structure. Adding Responsiveness with Tailwind CSS: Explain how to install and configure Tailwind CSS for styling and responsiveness. Implementing State Management with Zustand: Walk through how Zustand can manage chat states, making the app feel responsive and smooth. Integrating Sockets for Real-Time Updates: Show how to set up Socket.io on the frontend to enable real-time communication between users. Setting Up the React App: Begin by initializing a React app and setting up the basic folder structure. Setting Up the React App: Begin by initializing a React app and setting up the basic folder structure. Setting Up the React App: Adding Responsiveness with Tailwind CSS: Explain how to install and configure Tailwind CSS for styling and responsiveness. Adding Responsiveness with Tailwind CSS: Explain how to install and configure Tailwind CSS for styling and responsiveness. Adding Responsiveness with Tailwind CSS: Implementing State Management with Zustand: Walk through how Zustand can manage chat states, making the app feel responsive and smooth. Implementing State Management with Zustand: Walk through how Zustand can manage chat states, making the app feel responsive and smooth. Implementing State Management with Zustand: Integrating Sockets for Real-Time Updates: Show how to set up Socket.io on the frontend to enable real-time communication between users. Integrating Sockets for Real-Time Updates: Show how to set up Socket.io on the frontend to enable real-time communication between users. Integrating Sockets for Real-Time Updates: Backend Implementation Backend Implementation This section covers setting up a Node.js and Express server with MongoDB as the database and Socket.io for real-time messaging. Setting Up the Express Server: Go over the initial setup, including installing dependencies, configuring routes, and connecting to MongoDB. Integrating JWT for Authentication: Explain how to use JWT for user authentication, including token creation and validation. Handling File Uploads with Multer: Demonstrate how to integrate Multer to handle image and file uploads, including setting up file storage and managing uploads. Enabling Real-Time Messaging with Socket.io: Detail how Socket.io powers instant communication, allowing users to send and receive messages in real-time. Setting Up the Express Server: Go over the initial setup, including installing dependencies, configuring routes, and connecting to MongoDB. Setting Up the Express Server: Go over the initial setup, including installing dependencies, configuring routes, and connecting to MongoDB. Setting Up the Express Server: Integrating JWT for Authentication: Explain how to use JWT for user authentication, including token creation and validation. Integrating JWT for Authentication: Explain how to use JWT for user authentication, including token creation and validation. Integrating JWT for Authentication: Handling File Uploads with Multer: Demonstrate how to integrate Multer to handle image and file uploads, including setting up file storage and managing uploads. Handling File Uploads with Multer: Demonstrate how to integrate Multer to handle image and file uploads, including setting up file storage and managing uploads. Handling File Uploads with Multer: Enabling Real-Time Messaging with Socket.io: Detail how Socket.io powers instant communication, allowing users to send and receive messages in real-time. Enabling Real-Time Messaging with Socket.io: Detail how Socket.io powers instant communication, allowing users to send and receive messages in real-time. Enabling Real-Time Messaging with Socket.io: Check out the full 10+ Hour Video on my YouTube channel. YouTube channel. For more such Full Stack Apps, subscribe to my YouTube channel. https://www.youtube.com/watch?v=W3sOezpkGWI&embedable=true https://www.youtube.com/watch?v=W3sOezpkGWI&embedable=true

🔥here's How I Built a Stunning Chat App With React 🚀

When a project needs to be split How do successful projects usually get started? Quickly, without long discussions, in startup mode: we build features and deal with technical debt later. Under such conditions, it’s hard to establish an architecture that would allow the project to continue evolving after 5–7 years. The frontend part of our project was no exception. In this article, I’ll explain how we transitioned from a classic React application to a truly big project. So, we had a typical React 17 app. Redux + logic in thunks and middlewares. Custom SSR on Express. The project was actively growing, attracting new users, and gaining functionality. The complexity of the code increased, and after the Series A round of funding, the company allowed us to allocate up to 15% of our time to technical tasks. At this stage, the product development team began to split into “units”—this is what we call the teams which handle the app’s functionality (a specific user role or scenario). At this point, the frontend project saw its first optimisations: Client-side lazy loading of components
Optimising the Redux middleware call stack These optimisations allowed us to add new features to our React app for a few more years. The project eventually got Series B funding, so the number of frontend developers reached 30 and the size of the main bundle grew to 300 KB. The code's interdependence and task complexity indicated that it was time to break the app into parts. We started by improving the asynchronous loading of components using React Loadable. This allowed us to load not just components asynchronously but entire pages. React Loadable gave us the ability, with our SSR, to understand which parts of the app were touched when rendering the HTML, collect those JS files, and load them before the first client render. After that, we realised that the main issue was in the middleware and thunks, not in the code of our pages. So, we began splitting the business logic within them. Getting started We decided to divide the project into modules using a modern tool for microfrontends. Here are the challenges we faced: SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR.
Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. At this point, we had a 4 KB overhead per module and a few asynchronous pages using the microfrontend tool, but it still didn’t solve the main issue—splitting the business logic. In the end, we put a lot of effort into implementing the tool without gaining significant optimizations. This happened because, regardless of the tool you use, what’s most important is how you logically split the app’s parts. After that, we moved on to directly dividing the business logic, having first solved a few related issues. Data sharing What’s stopping us from separating a module from our app? First of all, the shared stores. Let’s look at this problem using the example of the ‘users’ store. It looks something like this: export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; Each of our future modules uses such a store in roughly the following way. UserIds are stored in objects used by our module, and in selectors, we fill them with data from the users store. Why was it done this way at the start of the project? For convenience, caching, and data normalisation. Data from modules is stored in one place and, in some cases, can be reused from the cache instead of being requested again. The problem is that such a reducer is part of the common store, and if all modules have access to the shared store, it increases module interdependence. So, we extracted such reducers into separate stores using Zustand. This allowed us to isolate modules from data they didn’t need, while maintaining data sharing and reactivity between modules. Event sharing between modules The next issue we solved was shared middleware. Let’s break this down using the example of socket middleware. As the name suggests, this middleware processes events coming through a WebSocket connection. The problem is that this single middleware processes events for the stores of almost all modules. We reorganized it as follows: we created a separate event bus based on EventEmitter, independent of Redux, and now the module that maintains the WebSocket connection produces messages straight into the event bus. This way, we managed to split the common logic and distribute it across modules. An important point here: when switching from dispatching events to EventEmitter, you don’t need to migrate all events, just those used in multiple modules. Events that happen and are handled within one module don’t need to be migrated to EventEmitter. It’s crucial to understand the list of modules you want to isolate. A few more things to mention Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render.
In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. After solving these issues, we began splitting the business logic into modules, reflecting the structure of how our company is divided into teams and areas of responsibility. Conclusion Our mistake was starting with a tool before logically dividing the modules. The correct order for modularisation in our case would have been: Logically divide the project into modules: make a list of modules.
Solve the main issues with shared stores, events, and the base component library.
Actually split the business logic.
Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. And in conclusion, I want to wish good luck to everyone who is starting to split their application into modules. It's a long journey, but the result is worth it. When a project needs to be split When a project needs to be split How do successful projects usually get started? Quickly, without long discussions, in startup mode: we build features and deal with technical debt later. Under such conditions, it’s hard to establish an architecture that would allow the project to continue evolving after 5–7 years. The frontend part of our project was no exception. In this article, I’ll explain how we transitioned from a classic React application to a truly big project. So, we had a typical React 17 app. Redux + logic in thunks and middlewares. Custom SSR on Express. The project was actively growing, attracting new users, and gaining functionality. The complexity of the code increased, and after the Series A round of funding, the company allowed us to allocate up to 15% of our time to technical tasks. At this stage, the product development team began to split into “units”—this is what we call the teams which handle the app’s functionality (a specific user role or scenario). At this point, the frontend project saw its first optimisations: Client-side lazy loading of components Optimising the Redux middleware call stack Client-side lazy loading of components Optimising the Redux middleware call stack These optimisations allowed us to add new features to our React app for a few more years. The project eventually got Series B funding, so the number of frontend developers reached 30 and the size of the main bundle grew to 300 KB. The code's interdependence and task complexity indicated that it was time to break the app into parts. We started by improving the asynchronous loading of components using React Loadable. This allowed us to load not just components asynchronously but entire pages. React Loadable gave us the ability, with our SSR, to understand which parts of the app were touched when rendering the HTML, collect those JS files, and load them before the first client render. After that, we realised that the main issue was in the middleware and thunks, not in the code of our pages. So, we began splitting the business logic within them. Getting started Getting started We decided to divide the project into modules using a modern tool for microfrontends. Here are the challenges we faced: SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR. Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. SSR Build — Most microfrontend tools didn’t support server-side rendering (SSR), so we manually adjusted the process to ensure all modules were bundled together during SSR. SSR Build Integration with Loadable — We needed a mechanism to determine which parts of the app were affected during SSR, so we had to integrate Loadable with the SSR modules. Since each module represented an independent Webpack build, Loadable couldn’t correlate the chunk names it needed with those already loaded out of the box. To fix this, we wrote a small Webpack plugin that preserved shared chunk names. We then exported the Webpack Stats file and taught Loadable to look for the necessary chunks across other modules during SSR. Integration with Loadable At this point, we had a 4 KB overhead per module and a few asynchronous pages using the microfrontend tool, but it still didn’t solve the main issue—splitting the business logic. In the end, we put a lot of effort into implementing the tool without gaining significant optimizations. This happened because, regardless of the tool you use, what’s most important is how you logically split the app’s parts. After that, we moved on to directly dividing the business logic, having first solved a few related issues. Data sharing Data sharing What’s stopping us from separating a module from our app? First of all, the shared stores. Let’s look at this problem using the example of the ‘users’ store. It looks something like this: export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; export type IUsersState = Record<IUserId, IUser>;
export const initialState: IUsersState = {}
export default function reducer(
    state: IUsersState = initialState,
    action: IAppAction,
): IUsersState {
    switch (action.type) {
        case USERS_SAVE: {
            return {
                ...state,
                ...action.users.reduce((acc, user) => {
                    acc[user.id] = user;
                    return acc;
                })
            }
        }
        // ...
    }
}; Each of our future modules uses such a store in roughly the following way. UserIds are stored in objects used by our module, and in selectors, we fill them with data from the users store. Why was it done this way at the start of the project? For convenience, caching, and data normalisation. Data from modules is stored in one place and, in some cases, can be reused from the cache instead of being requested again. The problem is that such a reducer is part of the common store, and if all modules have access to the shared store, it increases module interdependence. So, we extracted such reducers into separate stores using Zustand. This allowed us to isolate modules from data they didn’t need, while maintaining data sharing and reactivity between modules. Event sharing between modules Event sharing between modules The next issue we solved was shared middleware. Let’s break this down using the example of socket middleware. As the name suggests, this middleware processes events coming through a WebSocket connection. The problem is that this single middleware processes events for the stores of almost all modules. We reorganized it as follows: we created a separate event bus based on EventEmitter, independent of Redux, and now the module that maintains the WebSocket connection produces messages straight into the event bus. This way, we managed to split the common logic and distribute it across modules. An important point here: when switching from dispatching events to EventEmitter, you don’t need to migrate all events, just those used in multiple modules. Events that happen and are handled within one module don’t need to be migrated to EventEmitter. It’s crucial to understand the list of modules you want to isolate. A few more things to mention A few more things to mention Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render. In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. Upgrading to React 18 allowed us to remove some of the functionality of Loadable: there’s no longer a need to wait for all necessary chunks to load before performing the first render. In order to reuse styles in common components, such as buttons (Button), we created a component library and started reusing them across the app. After solving these issues, we began splitting the business logic into modules, reflecting the structure of how our company is divided into teams and areas of responsibility. Conclusion Conclusion Our mistake was starting with a tool before logically dividing the modules. The correct order for modularisation in our case would have been: Logically divide the project into modules: make a list of modules. Solve the main issues with shared stores, events, and the base component library. Actually split the business logic. Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. Logically divide the project into modules: make a list of modules. Solve the main issues with shared stores, events, and the base component library. Actually split the business logic. Implement improvements that are possible due to the modular system: separate deployment, isolation, etc. And in conclusion, I want to wish good luck to everyone who is starting to split their application into modules. It's a long journey, but the result is worth it.

Our Journey to Micro-Frontends

Replicache vs. The World: Solving Web App Sync Challenges with Cutting-Edge Technology

Frontend Architecture Pitfalls in Startups: Lessons From Experience

Top 12+ React Boilerplates and Starter Kits for 2024

After a decade of software engineering work (professional and personal), particularly in front-end development, I’ve crafted something I’m proud of. In this article, I’ll walk you through my ideal tech stack and the intricate decisions that shaped MeetMomentum. Join me as we explore the nuts and bolts of building a tool designed to revolutionize how we manage time across global time zones. Project Overview In today’s connected world, tools to track global timezones aren’t just a necessity; they’re a lifeline for professionals and travellers alike. Unfortunately, most calendar solutions do not offer effective multi-time zone support when scheduling and I personally faced many struggles because of this. That’s how I started to come up with the MeetMomentum vision. I wanted to build something that truly accounts for infinite time zones, visually and intuitively. I also wanted to make sure it integrates with my existing calendar, so I don't have to look at multiple screens just to book a single meeting. Design The design was one of the biggest challenges. There is a good reason why most applications don't support more than two time zones. It is not possible to fit all that information, in a digestible manner. At least not with the existing approach. The existing approach is having all five days aligned and invitees’ agendas overlapping. Instead, we flipped the calendar view on it’s side, presenting each invitee's schedule on their own horizontal line, offset by their unique time zone. To navigate the calender users can simply swipe or scroll horizontally, and by maintaining the offset, we ensure perfect time zone alignment, in a very clean manner. This is the core of our innovation, however, it came with a surprising set of technical challenges! Have a play on the final outcome here: https://www.meetmomentum.tech/ Technical Stack Before diving any deeper, let's start by painting the landscape. Embarking on any software project requires a solid foundation, and the technical stack is where it all begins. In the development of MeetMomentum, choosing the right technologies was crucial to ensure flexibility, efficiency, and scalability. Programming Languages Used: TypeScript/JavaScript


CSS


Markdown/MDX for the blog Frameworks and Libraries: We used pure tailwind for styling, with no extra component libraries, outside a few specific cases where we have utilized Headless UI. We used Framer Motion for more custom animations. Drizzle as a lightweight ORM for composing typesafe queries and managing schema migrations. TRPC for simple server-client connectivity. Zod for validation of data inputs. react-hook-form for user input with its great integration with zod. Tools and Development Environment: Currently, we’re just using npm but might lean into pnpm. We use prettier for formatting. Eslint with various plugins for React, typescript, etc. in order to catch simple issues. Nix is used to provide dependencies outside of node_modules. Stripe dev cli. Architecture Overview: The architecture leans serverless. Being on Vercel, we leverage functions for our serverside compute. As we use supabase, we can also utilize PostgREST and Row Level Security (RLS) to directly and securely access data in the database. And being React on NextJS we can lean into SSG and client-side processing. Database Management: As mentioned above the database is Postgres on Supabase with RLS and PostgREST being key plugins. Server Infrastructure: Hosting on Vercel. Design Patterns: Design patterns such as MVC don’t really map onto React very well. The general approach is to keep the state as close to where it’s used so updates are only triggered for relevant areas of the page. Optimizations can be made in cases where updates are triggered but inputs have not meaningfully changed. State that is important across the application is handled via Zustand. In some cases, components are split into the part that handles and provides state, and the part that is visual with elements and styles. This can help to build out the component’s style and debug without needing to replicate the exact state in a more real-world scenario. However, sometimes it’s easier to have a combined component just to get something finished. Continuous Integration/Continuous Deployment (CI/CD): Vercel integration with GH runs ‘build’ and we run most of our linting and tests as part of that build. With a focus on SSG and client-side processing server-side compute is reduced. The vast majority of server-side compute is tied to accounts that can be managed carefully, and Vercel has capabilities to defend against abuse such as a DDoS attack. So, in general, the platform should scale very well without much intervention. There is room to improve some actions so we can leverage caching more or consolidate some requests but these are not of high concern until we reach much larger scales and can be worked on in the background. Major Challenges As mentioned before, one of the biggest challenges was building the horizontal scroll for the scheduling offsets. This would technically be called an ‘infinite horizontal scroll sync,’ and it seems like we were the first use case for it! The reason why it was so challenging was managing the browsers’ performance while triggering many browser events due to scrolling and lining up timezones accounting for their offsets. Keep in mind that each horizontal line had to be kept independent, as the user could at any point change the order with our ‘drag and drop’ features. And to make things harder for ourselves, we also had multiple time pickers that worked by aligning the exact position of the scroller. We tried multiple approaches, like having individual hour elements, and had to restart on at least four different occasions. But the result was worth it! Another major challenge was transitioning from the public scheduler to a personalized one, that integrates with your agenda. This time, the problem lies in trying to fit the agenda-related information into a small horizontal view. To get to our fleshed-out product, we had to undertake a lot of iteration, trial and error, and of course, user feedback! We also faced multiple technical challenges, such as integrating with the Google Calendar APIs, getting permission to handle user’s data, and so on. Outcomes User feedback for MeetMomentum.tech has been very positive. Users enjoy the convenience and creativity aspects, but we are still very early in our journey. Stay tuned as we evolve, enhancing MeetMomentum.tech to better serve you and the global community; one update at a time. After a decade of software engineering work (professional and personal), particularly in front-end development, I’ve crafted something I’m proud of. In this article, I’ll walk you through my ideal tech stack and the intricate decisions that shaped MeetMomentum. Join me as we explore the nuts and bolts of building a tool designed to revolutionize how we manage time across global time zones. Project Overview In today’s connected world, tools to track global timezones aren’t just a necessity; they’re a lifeline for professionals and travellers alike. Unfortunately, most calendar solutions do not offer effective multi-time zone support when scheduling and I personally faced many struggles because of this. That’s how I started to come up with the MeetMomentum vision. I wanted to build something that truly accounts for infinite time zones, visually and intuitively. I also wanted to make sure it integrates with my existing calendar, so I don't have to look at multiple screens just to book a single meeting. Design The design was one of the biggest challenges. There is a good reason why most applications don't support more than two time zones. It is not possible to fit all that information, in a digestible manner. At least not with the existing approach. The existing approach is having all five days aligned and invitees’ agendas overlapping. Instead, we flipped the calendar view on it’s side, presenting each invitee's schedule on their own horizontal line, offset by their unique time zone. To navigate the calender users can simply swipe or scroll horizontally, and by maintaining the offset, we ensure perfect time zone alignment, in a very clean manner. This is the core of our innovation, however, it came with a surprising set of technical challenges! Have a play on the final outcome here: https://www.meetmomentum.tech/ https://www.meetmomentum.tech/ Technical Stack Before diving any deeper, let's start by painting the landscape. Embarking on any software project requires a solid foundation, and the technical stack is where it all begins. In the development of MeetMomentum, choosing the right technologies was crucial to ensure flexibility, efficiency, and scalability. Programming Languages Used: Programming Languages Used: TypeScript/JavaScript CSS Markdown/MDX for the blog TypeScript/JavaScript TypeScript/JavaScript CSS CSS Markdown/MDX for the blog Markdown/MDX for the blog Frameworks and Libraries: Frameworks and Libraries: We used pure tailwind for styling, with no extra component libraries, outside a few specific cases where we have utilized Headless UI. We used pure tailwind for styling, with no extra component libraries, outside a few specific cases where we have utilized Headless UI. We used Framer Motion for more custom animations. We used Framer Motion for more custom animations. Drizzle as a lightweight ORM for composing typesafe queries and managing schema migrations. Drizzle as a lightweight ORM for composing typesafe queries and managing schema migrations. TRPC for simple server-client connectivity. TRPC for simple server-client connectivity. Zod for validation of data inputs. Zod for validation of data inputs. react-hook-form for user input with its great integration with zod. react-hook-form for user input with its great integration with zod. react-hook-form for user input with its great integration with zod. Tools and Development Environment: Tools and Development Environment: Currently, we’re just using npm but might lean into pnpm. Currently, we’re just using npm but might lean into pnpm. We use prettier for formatting. We use prettier for formatting. Eslint with various plugins for React, typescript, etc. in order to catch simple issues. Eslint with various plugins for React, typescript, etc. in order to catch simple issues. Nix is used to provide dependencies outside of node_modules. Nix is used to provide dependencies outside of node_modules. Stripe dev cli. Stripe dev cli. Architecture Overview: Architecture Overview: The architecture leans serverless. Being on Vercel, we leverage functions for our serverside compute. As we use supabase, we can also utilize PostgREST and Row Level Security (RLS) to directly and securely access data in the database. And being React on NextJS we can lean into SSG and client-side processing. Database Management: Database Management: As mentioned above the database is Postgres on Supabase with RLS and PostgREST being key plugins. Server Infrastructure: Server Infrastructure: Hosting on Vercel. Design Patterns: Design Patterns: Design patterns such as MVC don’t really map onto React very well. The general approach is to keep the state as close to where it’s used so updates are only triggered for relevant areas of the page. Optimizations can be made in cases where updates are triggered but inputs have not meaningfully changed. State that is important across the application is handled via Zustand. In some cases, components are split into the part that handles and provides state, and the part that is visual with elements and styles. This can help to build out the component’s style and debug without needing to replicate the exact state in a more real-world scenario. However, sometimes it’s easier to have a combined component just to get something finished. Continuous Integration/Continuous Deployment (CI/CD): Continuous Integration/Continuous Deployment (CI/CD): Vercel integration with GH runs ‘build’ and we run most of our linting and tests as part of that build. With a focus on SSG and client-side processing server-side compute is reduced. The vast majority of server-side compute is tied to accounts that can be managed carefully, and Vercel has capabilities to defend against abuse such as a DDoS attack. So, in general, the platform should scale very well without much intervention. There is room to improve some actions so we can leverage caching more or consolidate some requests but these are not of high concern until we reach much larger scales and can be worked on in the background. Major Challenges As mentioned before, one of the biggest challenges was building the horizontal scroll for the scheduling offsets. This would technically be called an ‘infinite horizontal scroll sync,’ and it seems like we were the first use case for it! The reason why it was so challenging was managing the browsers’ performance while triggering many browser events due to scrolling and lining up timezones accounting for their offsets. Keep in mind that each horizontal line had to be kept independent, as the user could at any point change the order with our ‘drag and drop’ features. And to make things harder for ourselves, we also had multiple time pickers that worked by aligning the exact position of the scroller. We tried multiple approaches, like having individual hour elements, and had to restart on at least four different occasions. But the result was worth it! Another major challenge was transitioning from the public scheduler to a personalized one, that integrates with your agenda. This time, the problem lies in trying to fit the agenda-related information into a small horizontal view. To get to our fleshed-out product, we had to undertake a lot of iteration, trial and error, and of course, user feedback! We also faced multiple technical challenges, such as integrating with the Google Calendar APIs, getting permission to handle user’s data, and so on. Outcomes User feedback for MeetMomentum.tech has been very positive. Users enjoy the convenience and creativity aspects, but we are still very early in our journey. Stay tuned as we evolve, enhancing MeetMomentum.tech to better serve you and the global community; one update at a time.

How I Built MeetMomentum: Applying 10 Years of React Experience

Introduction In modern web development, the boundaries between classic and web applications are blurring every day. Today, we can create not only interactive websites but also full-fledged games right in the browser. One of the tools that makes this possible is the library - a powerful tool for creating 3D graphics based on using technology. React Three Fiber Three.js React In today's article, we will implement: add a new territory; connect typescript and configure absolute file paths; add an ammo counter; add reloading; hide the aiming point during aiming; work with sounds when firing and when the magazine is empty; add quick access slots interface with icons. Repository on GitHub Final demo: https://www.youtube.com/watch?v=XtL33-0fihc&embedable=true https://codesandbox.io/p/github/JI0PATA/fps-game?embedable=true Adding new territory In order to slightly diversify the territory through which the character can move, it was decided to replace it. There is a list on the official website. I chose this . From it, I took the territory model and imported it into my project. Since this room model already contains everything we need, we can immediately use it in our project. To do this, you will need to remove everything unnecessary in the file and use the imported model. I'll add it to the path . This (clicking on the link will download it) can be taken directly from the repository. of examples React Three Fiber demo Ground.jsx public/territory.glb model And at the same time, you can remove the floor surface texture from the project. floor.png Code section Connecting TypeScript and SCSS To make it more convenient to develop and maintain the application, let's connect . In this part, I will use it exclusively to develop some parts of the interface, but not yet to work with . TypeScript Three.js For example, how to add to an already created project can be found . TypeScript here Let's add two configuration files: and , as stated in the article above. tsconfig.json tsconfig.node.json tsconfig.json {
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    },
    "types": ["node"],

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true
  },
  "include": ["src"],
  "references": [{ "path": "./tsconfig.node.json" }]
} tsconfig.node.json {
  "compilerOptions": {
    "composite": true,
    "skipLibCheck": true,
    "module": "ESNext",
    "moduleResolution": "bundler",
    "allowSyntheticDefaultImports": true
  },
  "include": ["vite.config.js"]
} To simplify imports, we will make them with an absolute path. For example, these articles describe configs for and files. For files, the necessary rule has already been added (lines 8-11 in the file ). For regular JS files, you need to create a new file and add the appropriate rules there. JS TS TS tsconfig.json jsonconfig.json jsconfig.json {
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
} In the file, you can now change the paths to absolute ones, starting the paths with “ ” and making sure that everything works correctly. App.jsx @/ To avoid errors while working with for designs from , you will need to edit the file. And also install the appropriate packages. ESLint TypeScript .eslintrc.cjs npm i -D @types/node @typescript-eslint/eslint-plugin @typescript-eslint/parser To connect you will need to install it first. SCSS, npm i -D sass file to . We will also change the file extension of to and correct the path to the component and the styles file in accordance with the absolute path. Let's rename the index.css index.scss main.jsx main.tsx App After renaming to the extension, you will need to replace the path to the root file in the file. .tsx index.html To correct these errors, you will need to create a file with the following lines in the root of the declaration.d.ts src folder. declaration.d.ts declare module '*.scss';
declare module '*.jsx'; Let's get back to styles. Let's create a new file along the path . Let’s transfer the “sight” styles to the created file and use “modular classes.” src/UI/UI.module.scss Now we can use and in our project, and also use to import files. It is also necessary to change the paths in the remaining files to absolute ones for everything to work correctly. SCSS TypeScript absolute paths Code section Ammo counter Now, our weapons can fire indefinitely since they have no shot limit. To implement this limit, we will use to store states. zustand Let's create a new file along the path . In this file, we will use . Let's set the default number of cartridges, describe the interface of our storage, and create the storage itself. In it, we will describe the current number of cartridges (by default, the value is set from the variable ), a function for decreasing by one cartridge, and a function for reloading (setting the current number of cartridges to the default number). src/store/RoundsStore.ts TypeScript defaultCountOfRounds RoundsStore.ts import {create} from "zustand";

const defaultCountOfRounds = 30;

export interface IRoundsStore {
    countRounds: number;
    decreaseRounds: () => void;
    reloadRounds: () => void;
}

export const useRoundsStore = create<IRoundsStore>()((set) => ({
    countRounds: defaultCountOfRounds,
    decreaseRounds: () => set(({ countRounds }) => {
        return {
            countRounds: Math.max(countRounds - 1, 0)
        }
    }),
    reloadRounds: () => set(() => {
        return {
            countRounds: defaultCountOfRounds
        }
    })
})); Now, we can visually show the current state of the number of cartridges. Using the following path, we create two files: and . src/UI/NumberOfRounds/NumberOfRounds.tsx src/UI/NumberOfRounds/styles.module.scss Let's add styles for the counter element. styles.module.scss .rounds {
  display: flex;
  align-items: center;
  justify-content: center;
  width: 60px;
  height: 60px;
  position: absolute;
  right: 40px;
  bottom: 40px;
  background: rgba(255, 255, 255, .8);
  font-size: 40px;
  border-radius: 10px;
} Now, let’s implement the counter-visual element itself. In the state and get the current number of rounds. And then we will display either the number of remaining cartridges or the button that needs to be pressed. To make the application more flexible, it would be good to add the “button name” to the project configuration. Let's add two new fields to : one for the displayed name of the button and the second with the code of the key that needs to be pressed. NumberOfRounds.tsx file you will need to use the useRoundsStore .env Now, let's implement the file. NumberOfRounds.tsx import {useRoundsStore, IRoundsStore} from "@/store/RoundsStore.ts";
import styles from "@/UI/NumberOfRounds/styles.module.scss";

const RELOAD_BUTTON_NAME = import.meta.env.VITE_RELOAD_BUTTON_NAME;

const NumberOfRounds = () => {
    const countOfRounds = useRoundsStore((state: IRoundsStore) => state.countRounds);
    const isEmptyRounds = countOfRounds === 0;

    return (
        <div className={styles.rounds}>
            {!isEmptyRounds ? countOfRounds : RELOAD_BUTTON_NAME}
        </div>
    );
};

export default NumberOfRounds; However, because strictly checks everything, it currently does not know that such a configuration file can exist at all. There is also a chance that this variable may not be in the file, and then an error will appear while the application is running. Therefore, you will need to make some changes in order for code validation to start working correctly. TypeScript .env Let's add another value for to the file . types tsconfig.json Also, in the declaration.d.ts file, we will add an interface that will describe the structure of our .env so that TypeScript can perceive everything correctly. After the changes are made, all errors from the file should disappear. Now, you need to display the counter on the screen. At the same time, we currently have one more interface element - a sight. So now we can separate the UI elements from the 3D elements. To do this, let's create a new file . src/UI/UI.tsx Since we now have a separate folder for storing states, we can now move one of the states there, which we will need right now, namely: . Let's create a file in and bring it to the following form. Let's remove this state from the file and add imports of this state in the and files. A small digression. useAimingStore src/store/AimingStore.ts Weapon.jsx Weapon.jsx Player.jsx AimingStore.ts import {create} from "zustand";

export interface IAimingStore {
    isAiming: boolean;
    setIsAiming: (value: boolean ) => void;
}

export const useAimingStore = create<IAimingStore>()((set) => ({
    isAiming: false,
    setIsAiming: (value) => set(() => ({ isAiming: value }))
})); And now, let's implement the file. Let's move the crosshair into it, which will be displayed only if the player does not aim using the mouse button, and also add the newly created component there. UI.tsx NumberOfRounds UI.tsx import NumberOfRounds from "@/UI/NumberOfRounds/NumberOfRounds.tsx";
import {IAimingStore, useAimingStore} from "@/store/AimingStore.ts";
import styles from "@/UI/UI.module.scss";

const UI = () => {
    const isAiming = useAimingStore((state: IAimingStore) => state.isAiming);

    return (
        <div className="ui-root">
            {!isAiming && <div className={styles.aim} />}
            <NumberOfRounds/>
        </div>
    );
};

export default UI; Now, with each shot, you need to reduce the number by one cartridge. To do this, you will need to call the function from . And while the number of cartridges is equal to 0, then call the function. At the same time, at the moment, two shots will be fired per click, so it is necessary to correct the logic of the start of shots. decreaseRounds useRoundsStore reloadRounds Code section Reload Let's start implementing recharging. In this section, we implement the following logic: as long as there are cartridges, the weapon can fire, but as soon as they run out, the shooting stops, and when you press a given key, the default number of cartridges is restored. All changes will occur only in the file. You will need to import the reload key code from Then, get the state and function from , add a keypress event handler, and compare the pressed key with the key that is set to reload. And in the function, check the number of cartridges, and if it is 0, then do not perform any action. Accordingly, if you fire all the cartridges and then press the R key, then all actions and sounds will begin to play again. Weapon.jsx .env. useRoundsStore startShooting Code section Sounds when firing and when the magazine is empty Let's take a look at weapon sounds. At the moment, the sound of a shot has already been implemented. But when I try to shoot with an empty magazine, there is no sound. I have already selected the sound, so (clicking on the link will start downloading) can be downloaded from the commit of the current section. it Also, instead of using , you can use spatial audio, which is added to the scene and changes dynamically depending on various factors. To do this, you need to add the tag. You will also need to add several attributes: HTMLAudio PositionalAudio - indicates a link to the audio file; url - specify false, since this sound is called only during a certain action; autoplay - specify false since single playback is required; loop - set in order to gain access to an object for playing sound at a certain point in time. ref Code section Quick Access Slots Interface Now, we will implement the interface of quick access slots, into which the player can assign the necessary items. Let's start with the implementation of the storage. Let's create a file . Let's describe the slot type QuickAccessSlotsType, which stores some element in the form of a string (in this case, it will only be an item icon for now), as well as the IQuickAccessSlotsStore interface, which indicates that slots are an array of types. We also create the storage itself. src/store/QuickAccessSlotsStore.ts QuickAccessSlotsStore.ts import {create} from "zustand";
import default_slots from "@/quick_access_slots.json";

const SLOTS_COUNT = 5 as const;

type QuickAccessSlotsType = {
    item: string;
}

interface IQuickAccessSlotsStore {
    slots: QuickAccessSlotsType[];
}

export const useQuickAccessSlotsStore = create<IQuickAccessSlotsStore>()(() => ({
    slots: default_slots.concat(Array(SLOTS_COUNT - default_slots.length).fill({
        item: null
    }))
})); Let's create a sample file that will contain an array of some of the added items. We will also download several icons that we will use in the future. JSON quick_access_slots.json [
  {
    "item": "medicine/aid.png"
  },
  {
    "item": "weapons/mp5.png"
  },
  {
    "item": "weapons/ak.png"
  }
] Now, we need to create the user interface itself. This will be a number of slots with an icon inside and a number to activate this item. Let's create two files for styles and layout: and . src/UI/QuickAccessSlots/styles.module.scss src/UI/QuickAccessSlots/QuickAccessSlots.tsx Let's write styles. .slots {
  position: fixed;
  bottom: 40px;
  left: 50%;
  transform: translateX(-50%);
  display: flex;
  align-items: center;
  column-gap: 10px;

  .slot {
    position: relative;
    width: 60px;
    height: 60px;
    border-radius: 10px;
    border: 2px solid darkgray;
    background: rgba(255, 255, 255, .3);
    padding: 5px;
    transform: skew(-20deg, 0);

    img {
      width: 100%;
      height: 100%;
    }

    .key {
      position: absolute;
      z-index: 2;
      font-weight: bold;
    }
  }
} In file, we extract slots from storage and display them through a loop, adding a number inside each slot (element index + 1), and also check whether the slot is filled with something and, if so, display the image. the tsx QuickAccessSlots.tsx import {useQuickAccessSlotsStore} from "@/store/QuickAccessSlotsStore.ts";
import styles from "@/UI/QuickAccessSlots/styles.module.scss";

const QuickAccessSlots = () => {
    const slots = useQuickAccessSlotsStore((state) => state.slots);

    return (
        <div className={styles.slots}>
            {slots.map((slot, key) => (
                <div key={key} className={styles.slot}>
                    <span className={styles.key}>{key + 1}</span>
                    {slot.item && <img src={`/images/icons/${slot.item}`} alt={`${slot.item} ICON`}/>}
                </div>
            ))}
        </div>
    );
};

export default QuickAccessSlots; And at the end we add the created component to the root component . UI.tsx Code section Conclusion In this article, we added new territory, worked with sound, added an ammo counter with reloading, and also added quick access slots. In the next part, we will continue to improve our game, adding new functionality. Thanks for reading, and I'm happy to respond to comments! Also published . here

Creating Your Own 3D Shooter Using the React and Three.js Stack — Part 3

LONDON, United Kingdom, November 18th, 2024/Chainwire/--Plutus, a pioneer in tokenized loyalty rewards, is implementing strategic upgrades to enhance platform integrity and ensure long-term sustainability. Guided by community feedback, with 67% of users expressing support, the company is rolling out initiatives aligned with its whitepaper, including offering rewards of up to 10% on debit card payments, positioning itself as a competitive alternative to traditional cashback and credit card programs. Consequences Of Scaling Ambitions Since its inception in 2015 as one of the earliest community-supported Ethereum-based platforms, Plutus has pursued rapid growth while maintaining a self-funded approach. This expansion has introduced operational challenges that have, at times, affected the customer experience and community trust. Plutus is now dedicated to addressing these issues and strengthening the platform. Steps to Improve Platform Integrity and User Experience Helping Customers: Reinstated accounts flagged for misuse with guidance.
Enhancing Transparency: Updated terms and conditions offer clearer criteria and expectations for users.
Metal Card Extension: All holders affected by upgrades received +1 month free.
New Features: PlutusSwap, PlutusMiles, PlutusGift, and more for in-app value.
Tangible Benefits: Redeem for instant card-top ups, air miles or gift cards.
PLU Rewards Anchor: In-app redemptions and emissions at a minimum £/€10 value. A Future of Growth and Innovation By the end of 2024, all in-app utilities, except PlutusSwap, will be anchored to a minimum intrinsic value of £/€10 per PLU (e.g., 1 PLU = £10 Gift Card), making external market conditions irrelevant. Starting in Q1 2025, PLU emissions will also align with this £/€10 intrinsic value set by in-app utilities. This approach aligns with Ernst & Young’s forecast of £/€7.90 per PLU in-app, aimed at achieving 100% self-sustainability through our network fee system, FUEL, and establishing a 'FUD-proof' model. In a move toward greater transparency, Plutus plans to release its financial model as open-source, enabling public verification and contributing to industry innovation. “Some doubt the system’s scalability and naively compare it to standard cashback," said Plutus CEO Danial Daychopan. "To ease concerns, we're re-validating the model with Ernst & Young and making it publicly available—not only to reassure our community but also to guide others who try to replicate our success. This move supports the industry, inspires us to innovate further, and lets us confidently leave them behind” A Balanced Approach to Transparency Plutus remains committed to transparency and fairness, with a top priority of ensuring the rewards system remains sustainable. The company understands that not everyone will agree with every decision, and that’s okay. Plutus is using this time to focus on what truly benefits the community in the long run. While some long-time customers may not agree with the direction, the company apologises for any disappointment, but to ensure continued benefits for all PLU token holders, the product must evolve. Plutus doesn’t rely on fancy PR firms for polished statements – the company speaks directly and honestly with its community. While there may be missteps along the way, Plutus is committed to improving and ensuring its messages are clear, consistent, and aligned with its values. Looking Ahead Plutus prioritizes maintaining a secure, respectful environment as it prepares for growth and an upcoming Series A funding round with an industry-leading partner. This collaboration will support the 2025 network transition, enhancing Plutus' tokenomics while safeguarding the community and fostering a positive space for customers who share its values. With Tier 1 network support and funding, Plutus remains committed to transparency and sustainability, ensuring its position as a leader at scale and delivering lasting value to millions of customers.For more details on upcoming features, please visit: Plutus White Paper 2024 About Plutus Plutus is a leading rewards and finance platform, providing lucrative solutions for its community worldwide. Focused on transparency, trust, and organic long-term growth, Plutus empowers everyday card spenders with tokenised loyalty rewards that maximise value in any economy. Contact Plutus Team press@plutus.it This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here LONDON, United Kingdom, November 18th, 2024/Chainwire/--Plutus, a pioneer in tokenized loyalty rewards, is implementing strategic upgrades to enhance platform integrity and ensure long-term sustainability. Guided by community feedback, with 67% of users expressing support, the company is rolling out initiatives aligned with its whitepaper, including offering rewards of up to 10% on debit card payments, positioning itself as a competitive alternative to traditional cashback and credit card programs. LONDON, United Kingdom, November 18th, 2024/Chainwire/--Plutus, Consequences Of Scaling Ambitions Since its inception in 2015 as one of the earliest community-supported Ethereum-based platforms, Plutus has pursued rapid growth while maintaining a self-funded approach. This expansion has introduced operational challenges that have, at times, affected the customer experience and community trust. Plutus is now dedicated to addressing these issues and strengthening the platform. Steps to Improve Platform Integrity and User Experience Helping Customers: Reinstated accounts flagged for misuse with guidance. Enhancing Transparency: Updated terms and conditions offer clearer criteria and expectations for users. Metal Card Extension: All holders affected by upgrades received +1 month free. New Features: PlutusSwap, PlutusMiles, PlutusGift, and more for in-app value. Tangible Benefits: Redeem for instant card-top ups, air miles or gift cards. PLU Rewards Anchor: In-app redemptions and emissions at a minimum £/€10 value. Helping Customers: Reinstated accounts flagged for misuse with guidance. Enhancing Transparency: Updated terms and conditions offer clearer criteria and expectations for users. Metal Card Extension: All holders affected by upgrades received +1 month free. New Features: PlutusSwap, PlutusMiles, PlutusGift, and more for in-app value. Tangible Benefits: Redeem for instant card-top ups, air miles or gift cards. PLU Rewards Anchor: In-app redemptions and emissions at a minimum £/€10 value. A Future of Growth and Innovation By the end of 2024, all in-app utilities, except PlutusSwap, will be anchored to a minimum intrinsic value of £/€10 per PLU (e.g., 1 PLU = £10 Gift Card), making external market conditions irrelevant. Starting in Q1 2025, PLU emissions will also align with this £/€10 intrinsic value set by in-app utilities. This approach aligns with Ernst & Young’s forecast of £/€7.90 per PLU in-app, aimed at achieving 100% self-sustainability through our network fee system, FUEL, and establishing a 'FUD-proof' model. Ernst & Young’s forecast Ernst & Young’s forecast In a move toward greater transparency, Plutus plans to release its financial model as open-source, enabling public verification and contributing to industry innovation. “Some doubt the system’s scalability and naively compare it to standard cashback," said Plutus CEO Danial Daychopan. "To ease concerns, we're re-validating the model with Ernst & Young and making it publicly available—not only to reassure our community but also to guide others who try to replicate our success. This move supports the industry, inspires us to innovate further, and lets us confidently leave them behind” “Some doubt the system’s scalability and naively compare it to standard cashback," said Plutus CEO Danial Daychopan . "To ease concerns, we're re-validating the model with Ernst & Young and making it publicly available—not only to reassure our community but also to guide others who try to replicate our success. This move supports the industry, inspires us to innovate further, and lets us confidently leave them behind” Danial Daychopan Danial Daychopan A Balanced Approach to Transparency Plutus remains committed to transparency and fairness, with a top priority of ensuring the rewards system remains sustainable. The company understands that not everyone will agree with every decision, and that’s okay. Plutus is using this time to focus on what truly benefits the community in the long run. While some long-time customers may not agree with the direction, the company apologises for any disappointment, but to ensure continued benefits for all PLU token holders, the product must evolve. Plutus doesn’t rely on fancy PR firms for polished statements – the company speaks directly and honestly with its community. While there may be missteps along the way, Plutus is committed to improving and ensuring its messages are clear, consistent, and aligned with its values. Looking Ahead Plutus prioritizes maintaining a secure, respectful environment as it prepares for growth and an upcoming Series A funding round with an industry-leading partner. This collaboration will support the 2025 network transition, enhancing Plutus' tokenomics while safeguarding the community and fostering a positive space for customers who share its values. With Tier 1 network support and funding, Plutus remains committed to transparency and sustainability, ensuring its position as a leader at scale and delivering lasting value to millions of customers.For more details on upcoming features, please visit: Plutus White Paper 2024 Plutus White Paper 2024 Plutus White Paper 2024 About Plutus Plutus is a leading rewards and finance platform, providing lucrative solutions for its community worldwide. Focused on transparency, trust, and organic long-term growth, Plutus empowers everyday card spenders with tokenised loyalty rewards that maximise value in any economy. Plutus Plutus Contact Plutus Team press@plutus.it This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here here here

Plutus Announces Platform Enhancements To Bolster Transparency And Sustainability

بلوتوس تعلن عن تحسينات في المنصة لتعزيز الشفافية والاستدامة

প্লুটাস স্বচ্ছতা এবং স্থায়িত্ব বাড়াতে প্ল্যাটফর্মের উন্নতি ঘোষণা করেছে

Plutus anuncia mejoras en la plataforma para reforzar la transparencia y la sostenibilidad

Plutus annonce des améliorations de sa plateforme pour renforcer la transparence et la durabilité

Plutus Mengumumkan Peningkatan Platform untuk Meningkatkan Transparansi dan Keberlanjutan

Plutus、透明性と持続可能性を強化するためのプラットフォーム強化を発表

Plutus ашықтық пен тұрақтылықты арттыру үшін платформаның жақсартуларын жариялайды

Plutus Esakoli Ba Améliorations Ya Plateforme Pona Ko Bolster Transparence Na Durabilité

پلوٹس نے شفافیت اور پائیداری کو تقویت دینے کے لیے پلیٹ فارم میں اضافے کا اعلان کیا۔

I-Plutus Yazisa uPhuculo lweQonga lokuNxibelela elubala kunye noZinzo

Plutus 宣布改进平台以提高透明度和可持续性

I-Plutus Imemezela Izithuthukisi Zeplathifomu Ukuze Kuqinise Ukucaca Nokusimama

There are certain times in the history of investing when trends turn into full market swings, and it’s hard to find a better example than Environmental, Social, and Governance investing strategies. The focus for ESG investing was always on sustainability, corporate responsibility, and ethical governance, and it’s really reshaped how both individuals and institutional investors have allocated capital in the last decade. In recent years, though, ESG investing has been turned on its head. There have been many critics of the strategy, especially on performance metrics, and concerns about “greenwashing” have raised massive doubts about the true impacts of these strategies as well. It’s led to the growing debate: Is ESG investing losing its appeal, or is it evolving into a more mature and transparent market? The Rise of ESG Investing In the 1960s, there was a term for investing that was similar, called Socially Responsible Investing (SRI). This was really the beginning of ESG, but SRI investing mainly avoided certain industries, like tobacco and weapons. Over the decades, SRI evolved into the broader ESG framework, which gained significant traction in the 2000s. After the 2008 financial crisis, it grew even further as investors wanted safer, more responsible investment options. And by the 2010s, ESG transformed into a mainstream investment strategy from the niche offering it started as. The COVID-19 pandemic further accelerated growth in the area, as it highlighted how corporations can be important players in addressing global challenges. Maxim Manturov, head of investment research at Freedom24, explained: “The COVID-19 pandemic has made it clear that corporations play a crucial role in solving global problems. Governments alone cannot solve problems such as disease, climate change, workplace safety, or pay inequality based on gender and race. These problems affect people around the world and require the resources and expertise of corporations to address them. So, what makes a stock a good ESG investment? A good ESG company focuses on supporting environmental programmes, caring for its employees, making a positive contribution to local communities and delivering value to shareholders. It is important to validate its reputation through ESG rating agencies such as MSCI and Sustainalytics. Financial performance remains critical to ESG investing. As an ESG investor, you can promote responsible corporate behaviour without sacrificing returns. Institutional investors use ESG ratings to support the high standards of companies, and individual investors can do the same. By investing in leading ESG companies, you support initiatives such as energy efficiency, waste reduction, safer workplaces, and ethical business practices.” Globally, ESG investments are projected to continue with expansion. According to Bloomberg, ESG assets are expected to “reach over $40 trillion by 2030 – over 25% of” global assets under management. Europe is expected to be the leader of this sector with about $18 trillion in ESG assets, while the US may have slower growth due to political and economic challenges. Challenges Facing ESG Investing Recent years, however, haven’t been so rosy in the ESG investing space. The biggest challenge has been the issue of ‘greenwashing’, where companies falsely claim or exaggerate their environmental and social credentials to attract those ESG-conscious dollars. Many calls have been made to increase regulatory scrutiny and also standardisation of ESG reporting frameworks so there’s more transparency and accountability. According to Bloomberg Intelligence, this is exactly what will be needed to give more credibility to ESG investments and should help address some concerns about false claims and inconsistent ESG practices. The next issue for ESG investing is financial performance. A report from the Financial Times noted that ESG ETFs have underperformed their traditional counterparts over the past decade annually by 0.2 percentage points. Much was made about the outperformance in 2020 - often cited as ESG’s financial success, but it was largely a statistical outlier driven by sector biases, as ESG tends to be overweight in technology and underweight in energy, which drove much of the year’s success. Investor sentiment has since been mixed. Some remain committed to ESG for ethical reasons, while others question whether these funds are really delivering long-term returns. Is ESG Dead or Evolving? Despite the challenges facing ESG investing, it is likely evolving rather than dying as it enters a phase of slower growth and consolidation. It’s natural for any growth area or investing. As the market starts to mature, it needs better regulation and transparency. Once it has that and restores investor confidence, it may continue to grow. The core principles of sustainability, corporate responsibility, and governance aren’t going anywhere, especially in this transparent and data-driven digital age. However, to regain credibility, better analysis and accountability are needed. As for performance, there is likely a reason that ESG strategies are failing to outperform, according to Scientific Beta. They found that many ESG strategies rely on superficial ratings rather than the deep, fundamental analysis of companies - reinforcing the need for better ESG strategies that go beyond simple criteria. Evolution can lead to better outcomes for everyone in this scenario. Conclusion To bring it all together, ESG has had significant growth, but now, in its mature stage, there are many challenges. None of which are bigger than greenwashing and underperformance of assets. That being said, ESG is likely not dead - it is evolving. Long-term growth projections, alongside increased regulatory scrutiny, suggest that ESG investing should remain a big part of financial markets in the future. Investors, either ones that want to invest online or offline, should stay informed, understand the limitations of ESG strategies, and be mindful of greenwashing risks. There are certain times in the history of investing when trends turn into full market swings, and it’s hard to find a better example than Environmental, Social, and Governance investing strategies. The focus for ESG investing was always on sustainability, corporate responsibility, and ethical governance, and it’s really reshaped how both individuals and institutional investors have allocated capital in the last decade. In recent years, though, ESG investing has been turned on its head. There have been many critics of the strategy, especially on performance metrics, and concerns about “greenwashing” have raised massive doubts about the true impacts of these strategies as well. It’s led to the growing debate: Is ESG investing losing its appeal, or is it evolving into a more mature and transparent market? The Rise of ESG Investing In the 1960s, there was a term for investing that was similar, called Socially Responsible Investing (SRI). This was really the beginning of ESG, but SRI investing mainly avoided certain industries, like tobacco and weapons. Over the decades, SRI evolved into the broader ESG framework, which gained significant traction in the 2000s. After the 2008 financial crisis, it grew even further as investors wanted safer, more responsible investment options. And by the 2010s, ESG transformed into a mainstream investment strategy from the niche offering it started as. The COVID-19 pandemic further accelerated growth in the area, as it highlighted how corporations can be important players in addressing global challenges. Maxim Manturov, head of investment research at Freedom24, explained: “The COVID-19 pandemic has made it clear that corporations play a crucial role in solving global problems. Governments alone cannot solve problems such as disease, climate change, workplace safety, or pay inequality based on gender and race. These problems affect people around the world and require the resources and expertise of corporations to address them. So, what makes a stock a good ESG investment? A good ESG company focuses on supporting environmental programmes, caring for its employees, making a positive contribution to local communities and delivering value to shareholders. It is important to validate its reputation through ESG rating agencies such as MSCI and Sustainalytics. Financial performance remains critical to ESG investing. As an ESG investor, you can promote responsible corporate behaviour without sacrificing returns. Institutional investors use ESG ratings to support the high standards of companies, and individual investors can do the same. By investing in leading ESG companies, you support initiatives such as energy efficiency, waste reduction, safer workplaces, and ethical business practices.” Globally, ESG investments are projected to continue with expansion. According to Bloomberg , ESG assets are expected to “reach over $40 trillion by 2030 – over 25% of” global assets under management. Europe is expected to be the leader of this sector with about $18 trillion in ESG assets, while the US may have slower growth due to political and economic challenges. Bloomberg Bloomberg Challenges Facing ESG Investing Recent years, however, haven’t been so rosy in the ESG investing space. The biggest challenge has been the issue of ‘ greenwashing ’, where companies falsely claim or exaggerate their environmental and social credentials to attract those ESG-conscious dollars. Many calls have been made to increase regulatory scrutiny and also standardisation of ESG reporting frameworks so there’s more transparency and accountability. According to Bloomberg Intelligence , this is exactly what will be needed to give more credibility to ESG investments and should help address some concerns about false claims and inconsistent ESG practices. greenwashing greenwashing Bloomberg Intelligence Bloomberg Intelligence The next issue for ESG investing is financial performance. A report from the Financial Times noted that ESG ETFs have underperformed their traditional counterparts over the past decade annually by 0.2 percentage points. Much was made about the outperformance in 2020 - often cited as ESG’s financial success, but it was largely a statistical outlier driven by sector biases, as ESG tends to be overweight in technology and underweight in energy, which drove much of the year’s success. Financial Times Financial Times Investor sentiment has since been mixed. Some remain committed to ESG for ethical reasons, while others question whether these funds are really delivering long-term returns. Is ESG Dead or Evolving? Despite the challenges facing ESG investing, it is likely evolving rather than dying as it enters a phase of slower growth and consolidation. It’s natural for any growth area or investing. As the market starts to mature, it needs better regulation and transparency. Once it has that and restores investor confidence, it may continue to grow. The core principles of sustainability , corporate responsibility, and governance aren’t going anywhere, especially in this transparent and data-driven digital age. However, to regain credibility, better analysis and accountability are needed. sustainability As for performance, there is likely a reason that ESG strategies are failing to outperform, according to Scientific Beta. They found that many ESG strategies rely on superficial ratings rather than the deep, fundamental analysis of companies - reinforcing the need for better ESG strategies that go beyond simple criteria. Evolution can lead to better outcomes for everyone in this scenario. Conclusion To bring it all together, ESG has had significant growth, but now, in its mature stage, there are many challenges. None of which are bigger than greenwashing and underperformance of assets. That being said, ESG is likely not dead - it is evolving. Long-term growth projections, alongside increased regulatory scrutiny, suggest that ESG investing should remain a big part of financial markets in the future. Investors, either ones that want to invest online or offline, should stay informed, understand the limitations of ESG strategies, and be mindful of greenwashing risks.

Is ESG Investing Dead? The Rise and Fall of Sustainable Investing

¿Ha muerto la inversión ESG? El auge y la caída de la inversión sostenible

Onko ESG Investing kuollut? Kestävän sijoittamisen nousu ja lasku

האם ESG Investing מת? עלייתה ונפילתה של השקעות בר קיימא

ESG投資は終わったのか？持続可能な投資の興亡

Maty ve ny ESG Investing? Ny fiakarana sy ny fianjeran'ny fampiasam-bola maharitra

ESG Investing үхсэн үү? Тогтвортой хөрөнгө оруулалтын өсөлт ба уналт

Investițiile ESG sunt moarte? Creșterea și scăderea investițiilor durabile

ESG ኢንቨስትመንት ሞይቱ ድዩ? ምልዓልን ምውዳቕን ዘላቒ ወፍሪ

Patay na ba ang ESG Investing? Ang Pagtaas at Pagbagsak ng Sustainable Investing

Xana ESG Ku Vekisa Swi file? Ku Tlakuka na ku Wa ka Vuvekisi lebyi nga heriki

کیا ESG سرمایہ کاری ختم ہو گئی ہے؟ پائیدار سرمایہ کاری کا عروج اور زوال

ESG 投资已死？可持续投资的兴衰

Stories, News & Mentions about ZUSTAI

Zustai’s Stories on HackerNoon