Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Current focus: Templates #431

Open
tipiirai opened this issue Jan 17, 2025 · 2 comments
Open

Current focus: Templates #431

tipiirai opened this issue Jan 17, 2025 · 2 comments
Assignees
Labels

Comments

@tipiirai
Copy link
Contributor

Templates is the next major step on our roadmap:

These are complete, production-ready websites and apps that prove the value of systematic design. They are critical in Nue's journey to success because no JavaScript engineer truly understands Nue's potential until seeing it in action with their own eyes.

I'll focus solely on templates for the next few months, which means limited bandwidth for other features and improvements.

See https://nuejs.org/vision/ for the complete vision behind this effort.

@tipiirai tipiirai added the new feature New feature or request label Jan 17, 2025
@tipiirai tipiirai self-assigned this Jan 17, 2025
@tipiirai tipiirai removed the new feature New feature or request label Jan 17, 2025
@tipiirai tipiirai pinned this issue Jan 17, 2025
@tipiirai tipiirai added the major label Jan 17, 2025
@tipiirai
Copy link
Contributor Author

Something important to add here.

The JavaScript monolith dominates frontend development. It is deeply entrenched through institutional momentum, career incentives, and the comfort of established patterns. React skills pay the bills, while systematic design and web standards require deeper investment with less immediate payoff.

But this is precisely why focusing on templates and design systems is the right move. They demonstrate the power of separation of concerns in the most compelling way possible - through visual impact and maintainable systems. When teams see they can achieve Linear's sophistication or Stripe's polish through systematic design rather than component accumulation, it creates a natural path toward standards-first thinking.

The monolith won't disappear overnight, but showing better alternatives through working systems is more powerful than arguing against established patterns.

@JensRoland
Copy link
Contributor

Yes. Yes. Yes!!!!!!!

I think (purely in terms of terminology) that the React community would strongly disagree with calling what they do ‘monoliths’. Partly because they often live in a world of microfrontends and microservices, partly because the term ‘monolith’ has become a catchall boogeyman term for anything that is bad regardless of architecture.

What the React world has is indeed a front loaded client side monolith (plus or minus server side components and SSR), but it may be more constructive to call it ‘fat frontend’ (as we used to call it back in the 2012-2016 era) just to avoid the face-melting fury that ‘monolith’ can sometimes trigger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants