Make Solid.JS a fully featured Production Framework

[CordialGit]

Normally, JavaScript is powerful. It can do so much on the frontend. And it is a sufficient tool especially when paired with PHP, Node.Js or Deno.

Now, I'm offended that creators of JavaScript frameworks are now making Frontend Development too difficult.

THE PROBLEM
If I've taken the pain to learn HTML, CSS and JavaScript(which on its own, is powerful on the frontend). Then I'm going forward to learn a Framework like Solid.JS, or Vue or React(for example).

Why can't any of these, just be enough?

But No! -- I still keep being forced to learn much more!

In the case of Vue, I still need to learn Nuxt for Server Side Rendering, Pinia for State Management, Vuetify for Components, and Vitest for testing?

In the case of React, I still need to learn Next for Server Side Rendering, Flow or Redux for State Management, maybe Material UI for Components, maybe Styled Components for CSS-in-JS styling, and Jest for testing.

All of these over-learning is making frontend Development too difficult. They make frontend Development to become too complex and too difficult.

With so much frontend power in JavaScript already, can't these JavaScript Frameworks just come with those extra additional features in-built?

My wish now, is that a new framework will come along the way, and it will fix all these problems of Complexity.

It's frustrating learning too much and learning some new tools because of some ordinary small additional features--- small features that can simply be built into the Framework's Core.

THE ALTERNATIVE
I make websites with WordPress, and all the headaches that coding from scratch presents, are all taken away--while using WordPress.

With WordPress, a Database is already there. A Content creation Interface is already there. Admin Dashboard for managing Themes(Looks) and Plugins(Functionality) is already there. Everything you need is all there, and it's simply Drag-and-Drop to build your website.

The WordPress process is so easy, and it keeps evolving to make life and website development so easy.

MY REQUEST TO SOLID.JS
Make Solid.JS to become a fully featured Batteries-included framework like WordPress or Python.

This Fully Featured Batteries-Included Framework concept for Solid.JS would mean that, after the pain of learning JavaScript, and we then add Solid.JS on top of that JavaScript, we should need nothing more, as far as frontend is concerned.

So that all the things that Nuxt brings to Vue, or all the things that Next brings to React, should all be taken care of, by Solid.JS once and for all.

And we should not need again, another Framework on top of Solid.JS

IN PASSING
With a Batteries-Included Fully Featured approach for Solid.Js, it will move from being a "simple and performant reactivity for building user interfaces" to being called "the JavaScript Framework for Production Ready Apps".

In essence, I am asking that Solid.JS should make our life easier by being a fully featured Framework with a Batteries-Included approach--- where if we add Solid.JS on Top of JavaScript, we should need nothing more and nothing extra.

All the features that will make us need Nuxt, Vuetify, Pinia and Vitest---after learning Vue,

or all the features that will make us need Next, Redux, Styled Components, Jest--after learning React,

should all come as Core in-built features of Solid.JS-- so that once we add Solid.JS on Top of JavaScript, we should need nothing more and nothing extra.

Solid.JS should be the last and final step to learn after JavaScript, and it should take us straight into Production.

Regards.

[atk]

Wordpress is a CMS, Python is a programming language. Neither of them are frameworks. "Batteries included" is the quintessential antithesis to what a framework is.

That's not to say it would be impossible to create a full-featured CMS on top of solid (and as far as I know, there are already people working on this tedious task), but that's not what solid is.

[samuelstroschein]

@atk i think you are too technical in your response. whatever jquery, WordPress, etc. are, they help @CordialGit achieve something. namely, build an app/website without 20 different things to learn. imagine the following scenario:

"How do I build a web app?" and someone replies:

"You need a server framework - Node | Deno | Bun"
"You need a JS framework - SolidJS | React | Svelte | Vue | Angular"
"You need an app framework - SolidStart | Next | Nuxt | SvelteKit"
"You need auth framework - NextAuth | AuthJS | X"
"You need an i18n framework"
"You need an ..."

Outside of the JS ecosystem the answer is simply "Use Django.", "Use Flutter", "Use Ruby on Rails". I think that's what @CordialGit is referring to and ofc a potential for SolidJS. "How do I build a web app?" -> "Use SolidStart".

[atk]

And I think you're not technical enough in your criticism of my respone, @samuelstroschein. There are different sorts of packages for a reason - and that's true outside of the JS ecosystem as well. Saying "Why can't Solid.js should fulfil for me what WordPress does?" is inherently wrong, because it misunderstands the reason for what Solid.js is completely.

It doesn't matter if your CMS is written in PHP, Python or JS. It manages content, because that's what a CMS does. It's not a framework, because it needs to go a lot further than that. Likewise, it doesn't matter if your framework is written in Rust, Ruby on Rails or JS, because at the end of the day, it is just there so that the HTML gets into the DOM at the right place and things are interactive where they should be.

That's why I told @CordialGit that if what he wants fulfils the part of a CMS, he should go search for a CMS instead of criticizing a framework for not being a CMS.

[samuelstroschein]

@atk Don't get hung up on the CMS remark. Take a look at my "You need..." list ;)

I think we can agree that the JS ecosystem is severely fragmented (for reasons). Responding with "but Solid is only a framework and you need X in addition to build an app" is exactly what @CordialGit is criticizing.

Why do we need stuff like Jest/vite/etc? Why do we need all those extra bells and whistles just to build a web app? I know why but explaining to outsiders that "this is how the web ecosystem evolved and Solid is only a framework" will not satisfy potential adopters of SolidJS that are looking to build an app with one tool only :)

Anyhow, I just wanted to express that @CordialGit message received and I sympathize. The complexity of web apps prevents a "one tool to build apps" solution. But, things are slowly coming together with web standards, node having a test runner now, and more. It will, unfortunately, take time.

[atk]

I think you get me wrong again. Also, just about any language ecosystem is similarly fragmented. There is a very good reason to have small separate modules and it boils down to RFC 1925, #5: "It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea." - what you gain with just a "one thing does all" solution is reduced options. What you lose is options. What you don't get is a reduced learning curve, because this complex monolithic solution is still comprised of multiple fragments and once you dive deeper, there's still the same amount of things you need to know to make everything work like you want.

What @CordialGit and you are asking for is a platform that replaces the knowledge of a skilled developer. I have witnessed mutliple attempts to replace developers with code and seen all of them fail. It was true when back-end devs tried to replace front-end devs with Java-to-JavaScript transpilation and it still holds true even in the advent of sophisticated large-language-models. It's not that I as a skilled developer would be against such a platform; I would gladly help developing it. I just realize that it is simply impossible with the current state of tech and realistically will remain so for the next few centuries and thus, it is a fruitless endeavor and a waste of time.

[Tanay-Verma]

@CordialGit Just use Angular if you are so hung up on batteries included "frontend 'framework' "

[CordialGit]

And by PRs, you mean Public Repositories?

…

On Tue, Jun 13, 2023 at 6:07 AM SnnSnn ***@***.***> wrote: You can always open PRs. — Reply to this email directly, view it on GitHub <#1772 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARAA3WGNJQ3J6BARD2JTND3XK7YR3ANCNFSM6AAAAAAZDGAGSM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Innominus]

@CordialGit PR meaning Pull Request into the repository.