Salma Alam-Naylor

Posted on Jun 23, 2022 • Originally published at whitep4nth3r.com

Should I write a new JavaScript framework?

#webdev #javascript #programming #discuss

Each week, around 300 blazing-fast, game-changing, full-stack JavaScript frameworks are released into the developer ecosystem. They promise the discerning developer radical new approaches, life-affirming developer experiences, zero-config, maximum-config, all-bells, no-whistles, and the dopamine high of falling in love — over and over and over again.

Do you want to be a hero?

Open source maintainers of the billions of JavaScript frameworks now available for public consumption are worshipped as heroes of a new era, as they lead us boldly into a new landscape of JavaScript — and beyond.

And you're probably asking yourself — "Should I write a new JavaScript framework?"

What's the answer?

The answer to this question is far beyond the scope of this post. Instead, I built a website. This website takes you on an inspiring journey through the essential concepts to consider when building your new JavaScript framework, and gives you the confidence to finally mkdir bestframework.js && cd bestframework.js && git init.

Start your journey here.

Top comments (37)

hyrumwhite • Jun 24 '22

Counterpoint: yes.

Just dont expect it to take off. You'll learn a ton about what's going on under the hood of frameworks in general. And its fun.

Full disclosure: I'm currently writing a new JS framework.

Salma Alam-Naylor • Jun 24 '22

Fair point BUT you can also gain that same knowledge by contributing to an already existing framework under the mentorship of established contributors and as part of a team 😃

Jin • Jul 13 '22

You will never learn how to do something really new if you just follow someone else.

Wade Zimmerman • Jun 24 '22

Thank you for the inspiration. We need an alternative to React. Something that uses JSX but without hooks. Instead it should use ES6 classes. /s

Salma Alam-Naylor • Jun 24 '22

🤣

Jin • Jul 13 '22

JSX is not the best solution, but if you really want it, I recommend trying $mol_jsx, which fixes most JSX problems:

✅ The component automatically tracks external states (not only inner state).
✅ Component parameters are updated without a parent re-render.
✅ Changing the callback does not result in a re-render.
✅ Our hook counterpart can be applied anywhere in the code, even in loops and conditions.
✅ For partial updates, you can create a component that accepts callback.
✅ Stateful components are fully controllable.

Muhammad Uzair • Jun 24 '22

Classes don't have good class in JavaScript. 😁

eshimischi • Jun 24 '22

What??

૮༼⚆︿⚆༽つ • Jun 24 '22

Answer: let company like vercel or netlify burn their VC funding 🤑

I'm currently writing one 😂

don't ask why 😃

It start from me trying to participate in a game jam. Only some UI libs fit the rules so I try to write it myself (along with other whacky_helper.js). Now I got immersed to it and this is the 3rd rewrite 😅. A quick summary: it's a library that combine Reactive Programming and Entity Component System.

In the past there is a gitter chat that discuss Reactive Programming in JS. The author of Solidjs is very active in there. I wonder if there a similar chatroom or new forem for this that still active 🤔

Oxford Harrison • Jul 1 '22

You might find the Reactive Contexts Proposal for JavaScript very interesting.
Over here: github.com/webqit/subscript.

I got on that work to explore the possibility of having reactivity as part of the JavaScript language. You'd realise that we've stretched JavaScript in all directions to speak "reactivity"! Speaking it natively should be all that makes sense now.

૮༼⚆︿⚆༽つ • Jul 1 '22

Thanks. I only skim the explainer and have 2 question.

Why name it thread? Shouldn't that make it ambiguous with multi-threading 🤔
Does async function inside subcript function will do automatic tracking? AFAIK in async effect, automatic tracking only happen before await syntax. All reactive variable will not get tracked after await syntax.

References:

Automatic Dependency Detection a.k.a Automatic Tracking

Oxford Harrison • Jul 2 '22 • Edited

Valid questions!

In hind sight... thread() shouldn't be the best name for that function! I raised the first issue myself here: #5. Funny!

Thankfully, that should be only a name change! And it's entirely open to inputs, should you have something in mind! I once used the following reactive/react paradigms:

reactive function render() {
    // Function body
    console.log(externalVariable);
}
// Do first run
render();

// Change externalVariable
externalVariable = newValue;
render.react( ['externalVariable'] );

That is in hopes that react() sounds better, being that what it does is really to let the function react to its external dependencies!

I might need more clarity on the particular question. But inside of Subscript Function is a great Automatic Dependency Tracking system - but this time - based on a compiler-generated Dependency Graph. (Here, calls to react() actually execute along the relationships in this Dependency Graph. And the chain of statements executed is called a dependency thread.)

Talking about async/await... Subscript functions could be async functions...

reactive async function render() {
    // Function body
    let result = await fetch(externalVariable).then(response => response.json());
    console.log(result);
}
// Do first run
render(); // Promise

// Change externalVariable
externalVariable = newValue;
render.react( ['externalVariable'] ); // Promise

Now, on the above update, the console.log() expression only executes after the await fetch() expression resolves - as it would normally!

Code inside Subscript Functions do not change runtime expectations.

Jin • Jul 13 '22

Another way without syntax changing: AutoWire Proposal.

Salma Alam-Naylor • Jun 23 '22

Cheers for the helpful links!

Hristiyan Dodov • Jun 23 '22

Haha, recently I had thoughts about this exact same thing as well and wrote about it. Doing so, I came across this. The presence of such websites really speaks about the severity of our problem…

Salma Alam-Naylor • Jun 23 '22

Very nice article! You said much more than I did 😅

Sylwia Vargas • Jun 23 '22

I expected to be rickrolled and instead, I got a piece of amazing advice instead.
Please feel free to invoice me for your consultancy work 😂

Salma Alam-Naylor • Jun 23 '22

😂😂😂😂😂 Thank you for the best thing I’ve read all week 😂😂😂😂😂

Alex Lohr • Jun 23 '22 • Edited

I'm happy to say that I never finished or released the framework I once started to write, because while it would have gone in the same direction, it would never been as good as solid.js, which is now my favorite framework. I did help with the earlier versions of riot.js and wrote a few smaller libraries. In recent months, I wrote a few primitives for solid.js and one of them is already in production code and proven to work better than the alternatives (far smaller, faster, less bug-prone).

Still, I disagree with your sentiment. If you want a learning experience or an interesting hobby, by all means, write a framework or library. Just don't ever release it unless you can reliably prove that it does its job better than most others available on npmjs. And if it's not that good, don't feel bad about it. The best frameworks have grown over years and had the help of many very talented devs. You can't expect to best them so easily. Don't give up, you'll improve over time.

hyrumwhite • Jun 24 '22

What's the harm in releasing it?

Alex Lohr • Jun 24 '22

If it's not good, you're basically littering the package ecosystem with a bad package. You're responsible for all the problems arising from that.

Friday candour • Jun 25 '22

Nice

Andrew Baisden • Jun 26 '22

If you can dethrone the big 3 one day go ahead 😄

Jin • Jul 13 '22

I've already started, join in!

Muhammad Uzair • Jun 24 '22

Hell No, don't create new framework 😁, contribute to existing ones instead if you feel like you can make them better. Js community needs to settle on some standards.

Oxford Harrison • Jul 1 '22

I had wondered why our community would rather celebrate a framework monoculture than encourage making things standard. So, I decided to explore a path with the standards.

For reactivity, here's something I've been working on for a while now - the Reactive Context Proposal for JavaScript - github.com/webqit/subscript

Hoping that that's indeed exciting. 😃

Hussain Fazaal • Jun 24 '22

Yes Please 😁

View full discussion (37 comments)

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more

DEV Community

Should I write a new JavaScript framework?

Do you want to be a hero?

What's the answer?

Top comments (37)

Read next

Building a Developer-Friendly Workspace on a Budget

Disaster Recovery and Backup Strategies

2024 Update: Top 10 Alternatives to Postman

Building an Interactive Add To Cart Feature Using HTML, CSS, and JavaScript