skull

Robert Tamayo

R
B
blog
skull

Thoughts on an Object-Oriented Javascript Framework

I've been thinking about React again lately. Instead of pursuing a project in React, however, I started considering the possibility of creating another Javascript framework. 

This is the second time I'm considering a Javascript framework. I wrote about one earlier, which I called Ark. It was actually just a jQuery plugin that could inject data into templates. Looking back on it, I actually kind of like the api. It lets you create something like a blog post, then it lets you access the data used to render the html directly from jQuery. It's weird.

This time, I wanted something similar, but without jQuery. This time, I'm calling it Rex.

I was thinking of making Rex based entirely on Objects, using Javascript's classes and inheritance and so on.

But as I got to working on it, I realized that treating Javascript code as though it were Java is a little weird, at least when the goal is to create a webpage. I think that may be the main reason why I dislike some parts of React. It's not that I think React is unnecessary - it's that turning a webpage into a massive codebase seems unnecessary. I say that it seems unnecessary, not that it is; modern websites have so much going on that they have earned their rebranding into webapps

The main reason for frameworks at this stage in the game is to manage all of the data that goes into displaying html. The only thing I can think of for an object-oriented framework to do is to have a separate class store the html for each class that renders something. So, MVC-style. A model class will store the data, the view class stores the html template, and the controller class bosses everyone around.

But, why do in 3 classes what React does in one file? That's where I start to doubt this endeavor entirely.

I'll still have fun making something, but I don't know how far I'll get before I decide it's irrelevant.
 
Comments:
Leave a Comment
Submit