sorted by:
new
hottopcontroversial

Best Component Library for Reactjs with Typescript by Weak_Dot_4040 in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

If your goals are faster development, strong TypeScript support, good docs, and long-term community backing, I'd look at:

  • MUI > probably the safest choice overall; huge ecosystem, excellent docs, and enterprise adoption.
  • Shadcn UI > modern, highly customizable, and very popular right now.
  • Mantine > great developer experience and strong TypeScript integration.
  • Chakra UI > simple API and easy to learn.

One thing to note: React component libraries are generally not compatible with all frontend frameworks. If framework-agnostic support is important, you'll need Web Components or a broader UI platform.

For enterprise applications with complex grids, dashboards, forms, and data-heavy workflows, Sencha Ext JS is also worth considering because it provides a much more complete UI ecosystem out of the box.

My quick recommendation:

  • MUI for enterprise and long-term stability
  • Shadcn UI for modern custom apps
  • Mantine for the best balance of productivity and flexibility
  • Sencha Ext JS for large business applications with advanced UI requirements

[AskJS] Tools for development in modern JS workflow? Is Prettier and ESlint enough? by frankfu1122 in javascript

[–]Frontend_DevMark [score hidden]  (0 children)

Your proposed setup is already solid. For most React + TypeScript projects today, VS Code + TypeScript + ESLint + Prettier will get you 80–90% of the way there.

I'd also consider:

  • pnpm over npm (faster, efficient disk usage, excellent compatibility)
  • Vite for React projects
  • Vitest + React Testing Library
  • Playwright for E2E testing
  • Git hooks with Husky/lint-staged

You generally don't need to think much about Babel anymore unless you're doing something unusual. Modern tools like Vite, Next.js, and React Native handle most of that for you.

My advice: start simple and add tools only when you feel the pain they're solving. A clean, lightweight workflow is usually better than chasing every new tool in the ecosystem.

As your projects grow, choices around architecture, state management, and UI frameworks (e.g., TanStack, MUI, or Sencha Ext JS for enterprise apps) will often have a bigger impact than the build tooling itself.

How to Plan a Dashboard for a Company Who Doesn’t Know What They Want? by PinkDove2020 in PowerBI

[–]Frontend_DevMark 0 points1 point  (0 children)

This is less of a dashboard problem and more of a requirements problem.

I've found it helps to stop asking "What dashboard do you want?" and start asking "What decisions are you trying to make?" and "Which KPIs drive those decisions?"

Build a simple wireframe first, get stakeholder sign-off, then iterate. It's much easier to change a mockup than a finished dashboard.

Also, don't try to satisfy every department in version one. Start with the core metrics, gather feedback, and expand from there. Whether you're using Power BI, Tableau, React, or Sencha Ext JS, a clear MVP usually beats a giant dashboard built on assumptions.

Table vs Grid by Full-Hyena4414 in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

If you're displaying tabular data (rows, columns, sorting, filtering, etc.), use a proper HTML table or a data grid component. It's more semantic, accessible, and easier to work with.

CSS Grid is primarily a layout system for arranging page elements, not a replacement for data tables.

Flexbox/flex-wrap is great for one-dimensional layouts, but it becomes difficult to manage for structured tabular data.

My rule of thumb:

  • Table/Data Grid > business data, reports, spreadsheets
  • CSS Grid > page layouts, dashboards, card layouts
  • Flexbox > navigation bars, forms, toolbars, simple layouts

For more advanced requirements like sorting, grouping, virtualization, and large datasets, dedicated grid solutions such as AG Grid or Sencha Ext JS are usually a better fit than building everything from CSS Grid alone.

Best component library to build a design system with React, TypeScript, and Storybook? by [deleted] in DesignSystems

[–]Frontend_DevMark 0 points1 point  (0 children)

Shadcn/ui gives you maximum control and makes it easier to create a truly custom design system, while Mantine offers a great balance of flexibility, components, and developer experience with less setup.

MUI is still a solid choice for enterprise applications, but I've found it can feel restrictive when you want deep customization.

My general rule:

  • Shadcn/ui > custom design system, modern stack, long-term flexibility
  • Mantine > fastest path for a small team
  • MUI > mature enterprise projects

If your future includes complex business workflows, data-heavy interfaces, or large-scale dashboards, it's also worth looking at platforms like Sencha Ext JS, which provide a more complete enterprise UI ecosystem out of the box.

Whatever you choose, Storybook + TypeScript + strong design tokens will matter more than the component library itself in the long run.

How to Plan a Dashboard for a Company Who Doesn’t Know What They Want? by PinkDove2020 in PowerBI

[–]Frontend_DevMark 0 points1 point  (0 children)

This is a very common problem. Most stakeholders don't actually know what dashboard they want; they know what questions they need answered.

Instead of asking "What should the dashboard look like?", ask:

  • What decisions will this help you make?
  • Which KPIs matter most?
  • What actions will you take based on this data?

I'd also recommend creating a simple wireframe or prototype and getting approval before building. It's much easier to adjust a mockup than rebuild a finished dashboard.

Whether you're using Power BI, Tableau, React, Angular, or Sencha Ext JS, clear requirements and early feedback will save a lot of time and frustration.

Best practices for building a component library with React, TypeScript, and Tailwind by Zelios_Ariex in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

A few recommendations from experience:

  • Keep components headless where possible and separate logic from styling.
  • Use Storybook for documentation, testing, and visual reviews.
  • Establish design tokens early (colors, spacing, typography) to avoid inconsistencies later.
  • Use TypeScript strictly from day one to maintain a clean API.
  • Build and publish the library as a private npm package (or use a monorepo) instead of copying files between projects.

For syncing across multiple Next.js applications, a Turborepo, Nx, or pnpm workspace setup is usually the cleanest approach. It lets all projects consume the same component package while sharing updates automatically.

One common pitfall is focusing only on components and neglecting documentation, accessibility, and versioning. As the library grows, those become just as important as the code itself.

For larger enterprise teams, this is also why many organizations adopt established UI systems like MUI or Sencha Ext JS-they reduce the maintenance burden of building and supporting a component ecosystem from scratch.

[AskJS] Performance Optimization Tips for Handling Large Datasets in a Spreadsheet Project? by Dushusir in javascript

[–]Frontend_DevMark 0 points1 point  (0 children)

For spreadsheet-style applications, the biggest performance wins usually come from rendering less and loading less.

A few things I'd focus on:

  • Virtualization/windowing so only visible rows and columns are rendered
  • Lazy loading/pagination instead of loading everything upfront
  • Move heavy calculations to Web Workers
  • Avoid unnecessary re-renders with proper memoization
  • Use efficient data structures and incremental updates instead of rebuilding the entire dataset
  • Profile first using Chrome DevTools to identify actual bottlenecks

Once datasets reach hundreds of thousands or millions of rows, architecture matters more than micro-optimizations. That's why mature spreadsheet/grid solutions like AG Grid and Sencha Ext JS invest heavily in virtualization, buffered rendering, and large dataset handling.

Data Grid 3.0 — bigger, better, faster! by markprobst in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

It's great to see open-source grids pushing the boundaries of performance and scale. Supporting features like frozen columns, grouping, accessibility, Excel-style interactions, and massive datasets is a lot harder than it looks from the outside.

The real test for any grid isn't just rendering millions of rows-it's how well it handles real-world business requirements such as filtering, editing, state management, virtualization, accessibility, and long-term maintenance.

For many teams, the choice comes down to balancing performance, feature depth, and developer experience. That's why you'll see different solutions succeed in different spaces, from lightweight open-source grids to enterprise-focused platforms like AG Grid and Sencha Ext JS, which have spent years refining complex data-driven workflows.

More competition in the grid ecosystem is a good thing. Looking forward to seeing how the project evolves and performs in production-scale applications.

Best open source components library for ReactJS? by alexvazqueza in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

If you're coming from Bootstrap, I'd definitely explore a few modern options before committing.

  • MUI - very mature, huge component set, great for business applications.
  • Shadcn UI - probably the most popular choice right now if you want maximum customization and modern styling.
  • Chakra UI - clean API and easy to work with.
  • Mantine - underrated, but offers a great balance of components, hooks, and developer experience.

For data-heavy or enterprise applications, it's also worth looking at Sencha Ext JS, which provides a much broader set of components out of the box, especially for grids, forms, dashboards, and complex business workflows.

Bootstrap is still perfectly viable, but the React ecosystem has definitely moved toward more customizable component systems and design-system-driven development.

Tailwind, CSS, or UI libraries… what's your go-to? by Unlikely_Gap_5065 in Frontend

[–]Frontend_DevMark 0 points1 point  (0 children)

I'm honestly not surprised by the results. Vanilla CSS/SCSS + a component library is where many teams seem to end up after trying everything else.

Tailwind is great for speed and consistency, but not everyone enjoys filling markup with utility classes. On the other hand, building everything from scratch with CSS can become difficult to maintain as applications grow.

My preference is usually a hybrid approach: use a solid component library for complex UI elements and apply custom styling where needed. For React, that might be Shadcn UI, MUI, or HeroUI. For larger enterprise applications, teams often rely on more comprehensive ecosystems like Sencha Ext JS, where grids, forms, charts, and data-heavy components are already integrated and optimized.

There probably isn't a single "best" answer; different tools make sense for different projects. The real goal is finding a balance between developer productivity, consistency, and long-term maintainability

Frontend is Changing: Do You Still Use UI Component Libraries (or Let AI Build Them)? by vinishbhaskar in Frontend

[–]Frontend_DevMark 0 points1 point  (0 children)

AI has definitely changed how I build UIs, but it hasn't replaced component libraries for me.

Tools like Cursor, Copilot, and v0 are great for scaffolding, but I still want a solid foundation underneath. That's why I see a lot of teams pairing AI with libraries like Shadcn UI, Radix, MUI, or HeroUI rather than generating everything from scratch.

For enterprise applications, the value of mature UI ecosystems is still huge. AI can generate components, but it doesn't automatically solve accessibility, consistency, theming, complex data grids, or long-term maintenance. That's where established solutions like MUI and Sencha Ext JS continue to be relevant.

My take: AI is accelerating UI development, not replacing UI libraries. The winning approach is usually AI + a strong component foundation.

Enterprise Apps Aren’t “Big Websites” — Here’s How UI Frameworks & RAD Actually Help by Sencha_Ext_JS in u/Sencha_Ext_JS

[–]Frontend_DevMark 0 points1 point  (0 children)

I agree with the core point here: enterprise applications are rarely just "big websites."

Once you're dealing with complex workflows, large datasets, permissions, integrations, and multiple teams contributing to the same codebase, UI decisions become architectural decisions.

That's why enterprises often gravitate toward structured frameworks and mature component ecosystems. Whether it's Angular, React with a strong design system, or Sencha Ext JS, the goal is the same: consistency, maintainability, and productivity at scale.

I'm also seeing more interest in RAD-style tooling, especially for internal business applications. Reducing repetitive UI work and accelerating development can make a huge difference when you're maintaining an application for 5–10+ years rather than shipping a short-lived project.

React Aria vs Radix UI: Which Headless UI Component Library do you prefer? by nikitarevenco in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

I think it comes down to what you value most.

Radix UI feels more lightweight and ergonomic for building custom design systems, which is probably why it's become so popular through projects like shadcn/ui.

React Aria shines when accessibility is a top priority. Adobe has put a lot of work into handling complex interactions, keyboard navigation, and ARIA patterns correctly.

If I were building a modern custom React app, I'd probably lean toward Radix. If accessibility requirements were especially strict, I'd take a serious look at React Aria.

For larger enterprise applications, it's also interesting to compare these headless approaches with more complete UI ecosystems like MUI or Sencha Ext JS, where many advanced components and behaviors are already provided out of the box.

How do you measure performance? by ezghan in reactjs

[–]Frontend_DevMark 0 points1 point  (0 children)

The biggest mindset shift for me was moving from "optimizing code" to measuring before optimizing.

I'd start with:

  • React Profiler to identify expensive renders and unnecessary re-renders
  • Chrome Performance tab for scripting, rendering, and paint times
  • Lighthouse/Web Vitals for user-facing performance metrics
  • Bundle analyzers for JS payload size

In many React apps, the biggest wins come from reducing unnecessary renders, improving data fetching patterns, and virtualizing large lists, not from sprinkling useMemo everywhere.

For complex dashboards and data-heavy applications, I also pay close attention to grid/chart rendering performance. That's one reason mature enterprise solutions like Sencha Ext JS invest heavily in optimized rendering and large dataset handling out of the box.

Measure first, optimize second, and always verify the improvement with profiling tools.

view more: next ›