EDIT: I'm the author of RawJS. Everyone, please cool your jets. Omitting this on the main article was an oversight, and my authorship of this libra...
For further actions, you may consider blocking this person and/or reporting abuse
Just in case anyone else got mislead by the deceptive way this article was written, RawJS and HatJS aren't "hidden gem" libraries you simply hadn't heard of yet, they are virtually unused & untested libraries written by the author of this blog. Similarly, "Anonymous Controller Classes" aren't a paradigm you simply haven't been exposed to before - they're another invention of the author.
I admit that this was quite appealing to me as I was reading, however half of that appeal was the feeling of discovering a new paradigm that had been battle-tested and is emerging as a contender in the field, like when I first discovered Rust. Going to the GitHub to see what the community was like and finding it utterly nonexistent - zero issues, zero PRs not by the author, zero discussion - makes me feel as though I've been deceived by clever wording. You should reword this to make it clear you're the author of these libraries and the ACC concept.
I'm sorry you were mislead but that wasn't the intention. It was clearly stated in my bio that I'm the author of RawJS. People are skipping over that and then assuming that I'm trying to deceive people.
RawJS has been in development for over a year, and it's been the subject of considerable pressure by numerous apps, from large to small, mobile (Capacitor) to web. It works. There are essentially no known bugs. Because the library is very tiny (2.3KB) and actually doesn't do much (by design) so it's not terribly difficult to get to that point. Everything that has been committed in the last little while has been minor enhancements to address edge-case scenarios that don't affect main-line development.
Nowhere in the article did I ever say that this technique was an "emerging as a contender in the field". I'm simply sharing my actual experiences, and being completely honest that I personally see no reason to use any framework ever again, and my observation is that I see a lot of people getting tired of React, and moving to vanilla JavaScript, either by inheriting from HTMLElement or otherwise.
My general take is that I came down too hard on people's sacred cows, and now I'm experiencing the brunt of it. Frameworks tend to be extremely territorial, because if one's framework of choice loses popularity or becomes seen as stale/old, this diminishes the value of their time investment. So when their framework of choice is threatened, some will kick into an emotional state and jump to all sorts of petty attacks, maybe without even realizing they're doing this.
I'm glad the disclaimer is in your bio, unfortunately that doesn't show up on mobile so I never saw it.
When I say "battle-tested" I mean adopted by many people for many widely varied projects of various scales and requirements. It's great that you've fixed all the bugs you know about, but that speaks nothing to edge cases that haven't been tried yet or pain points encountered when people try to use your library for a specific use case. Every library has these pain points and I was very interested to read about yours. For example, Svelte has dozens of these, ranging from scoped styles not applying to components to a total lack of real error boundaries. Because your library has no discussion of these, I would have to take a gamble and discover the pain points for myself, along with workarounds since there'll be no supporting ecosystem around your library to tap into.
I struggle to believe the post wasn't worded the way it was with the intention of being deceptive. The article begins by comparing your discovery of TypeScript - an experience I'm familiar with - to your discovery of RawJS. But these experiences are nothing alike because you wrote RawJS to meet your needs. Furthermore, posing questions like "Why is no one talking about Anonymous Controller Classes?" implies that this is an established concept that you stumbled upon and believe is underrated. There are dozens of other ways to communicate this point that don't come off as deceptive, like "Introducing Anonymous Controller Classes" to make it clear that you are introducing a new concept to us.
I think it's unfortunate that you're choosing to deflect these criticisms from myself and other commenters by suggesting that we're unknowingly "kicking into an emotional state" in a territorial defense of our beloved frameworks. This is a way to at once dismiss our concerns and minimize our intellectual agency in making them. It's fine to disagree with my reading, but I'd prefer you leave it at that without attempting to gaslight me into believing I wrongly made the criticism while in an irrationally emotional state. I also just disagree wholeheartedly with this suggestion, because as mentioned in my first comment I was actually rather excited upon reading this, and I have no particular love for React specifically.
Sure, I guess that's reasonable that my comparison to TypeScript could have been misleading. Though I feel as though RawJS is a discovered technique. I'm certainly not the first to make a better document.createElement(). There are others, even some library authors of similar tools showing support in the comments.
I honestly don't know why other people aren't using Anonymous Controller Classes. It's a new term but I doubt it's a new thing. It's too basic. I understand how this could be deceptive... but does this really matter? It's a technique. It works for me and others. Do you think its dumb? No problem! Don't use it.
It's quite obvious that people are jumping to an emotional state.
A non-emotional comment looks like:
"Hmm interesting idea. How would you handle situation X?"
An emotional comment looks like:
"Your ideas are misguided. You don't know what you're talking about because I need feature X to handle situation Y".
Read through the comments. A lot of them read like the latter. You cannot reasonably deny that people are not jumping into an emotional state (though I will grant you that you seem like one of the more level-headed ones)
I find it hard to believe that people are getting worked up because some author made a disclosure in his bio, but didn't do so in the article when it was first posted. There is absolutely some amount of territorialism going on, though we may disagree on the degree.
And now you're accusing me of gaslighting you, without realizing that I've been the last 3 hours writing replies to every single person who responded, trying my best to handle their concerns (even the ones that are clearly out to attack me).
I'm not going to jump down your throat or anything (seems like you've had enough of that), but I still will say that this response is a huge deflection. You strike me as an intelligent enough person, which is also why I know you're being intentionally obtuse. This is very clearly an article written from the perspective of someone who "discovered" a pre-existing technology as if they have had no prior exposure to it. The fact that you created the product means you have plenty of exposure to it. So why is the tone written as if you've never heard of it until now? Well, to market the product of course. And more power to you! Nothing wrong with marketing. But just own it I guess. The tone of the article is not written as a creator but a consumer.
That being said, RawJS sounds awesome! Good job. I look forward to following the progress.Edit: Ah nevermind. The way you handled perfectly reasonable comments below changed my opinion again. No accountability whatsoever.
Please point out where I've taken "no accountability whatsoever". That is extremely unfair. It's 1:00 am, and I've been up since about 9:00am and I feel like I've literally done nothing but take accountability where it is due.
About "discovery", please understand where I'm coming from. I was the author of a real-time compiler for a "discovered" language rather than an "invented" one: (github.com/paul-go/truth) There is a difference between the two. I can agree this is an esoteric concept that most people don't have much exposure to.
Wow, this may be one of the first supportive comments I've received all day.
I don't know much about your project, but maybe you could start by taking a look at the sample app here:
rawjssample.pages.dev/
Hey, I was supportive, wasn't I? I just said it felt too niche.
Lol yes, you were one of the better ones ;-)
You're probably right about it being niche, at least for now while the support / help base is low and the flex of the library is for situations where you're building UIs that diverge significantly from the usual business form-filling apps.
Well said and based. I was getting hyped myself for a second but it was shortlived. Just like he Paul G rawvolution 😅
I've been around long enough to have been uneasy from almost the moment I started reading this article. All the best pitches are boring, dull, nuanced affairs. They usually come with a deadpan delivery from someone who has been in the trenches looking at pros and cons for a few days/weeks/months. This kind of excitable, "omg this is so cool" dog with a bone kinda stuff is almost always biased/driven by something that the individual is intellectually enamored with rather than objectively appraising.
A bit of advice for others who find themselves doing this (as I have many times): don't sell your integrity for the sake of the latest thing you think is cool. You'll quickly get a reputation and people will stop trusting your ability to be objective.
The whole article is either incredibly naive or incredibly disingenuous. After finding out that the author wrote the library and given the way this article is written, I'm leaning towards the latter. This article could have been phrased as an honest exploration or a prompt for discussion. But it's not, it's written as a misrepresentative, one-sided sales pitch.
Further, if I try an put aside the skepticism and engage with the article itself, the whole thing is a bit bizarre.
Fundamentally, the big message in this article seems to be to eschew MVU/ELM architectures and state-driven applications in general. It's basically saying you can munge your model and your view into the same thing.. I almost don't know what to say to that.
The class-based "component" was already worrying (we moved away from them in React for some very good reasons..) but then the idea of having to constantly dive into the DOM to ascertain state is just too much. Do people not remember the jQuery days? I almost can't believe that such a step backwards is being unironically espoused in 2024.
The author calls React bloated, but at its core, the premise of React is incredibly simple, and a decade or so ago, was the answer to many of the issues that the approaches being pitched here were causing when trying to build large web applications:
All a React component is, is something that transforms state into a view. The author calls the view and the model (state) "two representations of the same thing" - but that's just not true. Why not just get rid of the database too? Data & presentation of data are two separate things. Why on God's green earth would I want to fetch a JSON array from an API, map it to DOM nodes to present it, then traverse those same nodes and transform them back into data (and pray nothing else had touched them) every time I want to access or manipulate the list somehow?
You wouldn't want to use the DOM as your source of truth for the same reason you wouldn't monkeypatch shared globals. You don't own it, it's too easy for things to change unexpectedly. There are a myriad of reasons why a browser, browser extension, user script etc would want to touch/manipulate the DOM. Not only is it a rubbish format for data storage, it's also an very brittle medium.
I've not even talked about so many other things like how imperative this approach is, how much time you'd waste with low-level concerns that can be abstracted instead of writing actual business logic etc
This whole thing smells of Not Invented Here syndrome. Sorry.
You nailed it, couldn't agree more.
All I can say in response to this is: tell me without telling me you simply don't know how to build a well-organized vanilla JavaScript app.
You're not the target market. You want a framework to tell you what to do. A lot of developers fall into this category. You should keep doing that, it sounds like it's working out for you. For the stuff I build, I need freedom and control.
I've been developing for the web long before anything you could call a framework even existed but that's not the point. It doesn't matter whether I do or don't. You're saying "build a well-organized vanilla JavaScript app" but you're not talking about vanilla JS. You're just talking about a different framework (one that you apparently built). I mean FFS the whole thing is Typescript-based, and you're calling it "Raw JS".
Let's be clear, you're not asking people to move away from React and co into the absence of anything at all (which would be a big enough waste of time) - you're just asking people to trade their mature, battle-tested patterns and approaches to come play in your sandbox.
What a weird thing to say about React. In all your criticisms of React you failed to mention one of its biggest failings: it's actually so unopinionated that every project seems to have a different set of patterns/standards.
But that aside, you're damn right I want a framework to tell me what to do, just like I want strong patterns and good abstractions of low-level common implementation details. Like most developers, my day job is writing business logic, not imperatively reinvent the wheel to fix problems that don't exist/matter.
TypeScript is optional. You don't need to use it with RawJS if you don't want. This is the first I've heard of someone who understands "vanilla JavaScript" to mean: no TypeScript, no tailwind, no outside help from anything at all. It usually means "no frameworks that force upon you data-binding, state management, and a multitude of other things".
"you're just asking people to trade their mature, battle-tested patterns and approaches to come play in your sandbox."
No. "My sandbox" in this case is the W3C DOM. I don't own that. I think you're thinking that RawJS is just some other framework that might as well just be another React or Svelte, though one that has fewer features. This is wrong. It's a minimal document.createElement() abstraction, and the point of the article is that either this abstraction (or another, as some other library authors have commented), is all you really need.
"But that aside, you're damn right I want a framework to tell me what to do" <-- This wasn't a knock.
If it's not a framework or something that can be "implemented" then what are you even pitching here? A bespoke approach to every project?
Also.. of course it's minimal, it's a borderline proof-of-concept piece. You're not comparing apples and apples.
If this is really to be a serious approach for building complex web applications for large, diverse groups of people you'll have to solve all of the same problems as the major frameworks.
It's basically the 80/20 rule. I'm sure I could write a version of React that delivers 80% of the functionality with 20% of the code size (Isn't that basically what Svelte is? :D). But that last 20% is what makes it a robust solution for enterprises and SMEs around the world.
Just in your first example alone it's so easy to read ahead and see how quickly that would baloon out and become just as complex (likely more-so) than modern React and co once you start scaling up.
You're not the first person to come up with this, e.g. xxxxx (edit: company name redacted just in case) rolled their own typescript-first "no framework" approach when Flash died. It's eerily similar in intent and approach to what you propose. So what challenges do they have a decade or so in?
React.createElementera).If your message is meant to be that this is a great approach for quick prototyping or proof-of-concepts, then great. But bespoke code is always a dream at first. It's after none of the original developers are left and you've had to extend the functionality and refactor it a few times that you see if it's worth anything. Too much of what I see here is too similar to stuff I spent a lot of time trying to get away from for my comfort.
Pertinent, objective and to the point.
This is such a telling response to solid and reasonable criticism.
It wasn't reasonable though. It was laced with insults and excessive disagreeableness, and was written like you assumed I started programming 6 months ago. So I returned the favour.
It's like this––I've gone down every single path of reasoning you've articulated. Every one of the points you've brought up are reasonable objections, but as a person with many years of large-scale vanilla JavaScript app development under my belt, I've spent the time to develop a number of strategies to mitigate them. Hence the reply "tell me without telling me..."
A proper response to these objections probably requires an entire dev.to article. Which I plan to write some day.
Bro is this you? Being reasonable
His arguments for why one shouldn't store state in the DOM are completely right, and you don't even attempt to refute them. After anyone has read the arguments and understand them, attacking the person who first uttered them does not resolve the criticism.
A new article will be coming that covers the omissions made in this one. Give me a follow if interested! 👍
(That said, there is a thread somewhere in the depths of this comment section where there is some discussion about storing local component state within the DOM with good success)
I was curious about the progress of your framework, but this some of the most pretentious, degrading, and disingenuous replies I've ever read in my short career as an engineer.
@ceuk provided honest, sound, and respectful criticism even though he didn't have to.
I will be blocking you and hope to never see any technology or article of yours going forward.
I found his tone to be quite unwilling to engage in productive ideation, he had clearly already made up his mind to be dismissive, so I chose not to respond with anything meaningful (that, and there were about 50 other comments I needed to get through at the time). If he wants to come back and have an open-minded back and forth, I'm all ears!
It’s a super interesting concept but after reading through comments and investigating GitHub, I agree this is a pitch by the author of the project and this design called ACC. You still need typescript, this isn’t even written in vanilla JavaScript itself. That’s the biggest anti-pattern in the article.
Kind of glaring to call it RawJS and give very few examples, not to mention it’s a library, not a actual new thing. Your article is written as someone discovering the project and using it. It’s fine to be proud but it’s deceitful for the article to be written this way. I can’t even find any real world examples besides some color swatches on a page that actually doesn’t operate correctly. Big ideas for something clearly not vetted, reviewed, or have contributors.
It was an oversight. The article was updated.
"Vanilla JavaScript" usually doesn't preclude TypeScript. It typically means "no react / vue / whatever".
Vanilla js is vanilla js. Typescript is a superset of vanilla js, and is not vanilla js. It typically means "no framework". RawJS is a framework and is not vanilla js. Saying your framework is vanilla is like saying jquery is vanilla. It's not. It's a framework.
Vanilla "typically" means "raw". Build using the engine provided APIs. Just because you call it "RawJS" doesn't make it so.
RawJS isn't a framework. Its a micro-library. There is a difference. There are other micro-libraries that solve a similar problem set as RawJS. Some are linked in this comment section.
Using your vocabulary, if I use even a single dependency, I've now exited the realm of vanilla JavaScript. This is a bit silly.
😂 using a dependent is not vanilla js. They're not exclusive. That runs through a library that doesn't exist in the engine is not vanilla. Your module is no less a framework than react is. Where exactly do you draw the line that is "micro"? Exactly how many lines is that?
Your code doesnt do one thing and one thing well. It is a framework for DOM management. Just because it's not using a virtual dom doesn't make it not a framework.
function createDiv() { return document.createElement("div"); }OMG FRAMEWORK WHERE DID VANILLA JS GO??You very obviously don't understand what RawJS does, possibly some of that is my fault for not explaining things better, but either way I'm done with this childish conversation.
Your inability to accept reality and immediately getting angry and defensive with every single person who disagree with you is hilarious
I do not think RawJS is a framework. It’s a library (which is different from a framework).
Your code calls a library.
In a framework you will have some inversion of control happening (your code is called by the framework).
Thank you for the reasonable explanation. The phrase "inversion of control" escaped me 👍
OMG… take it easy with your judgement, mate!!! I think this is an excellent opportunity to start thinking about what really React and similar libraries are all about and maybe have an independent mindset. The complexity and all the prerequisites that a developer needs just to run React is absurd so well done for proposing a new way forward.
I disagree. If you're the author of a library, this post must say that. The way it is written, it is deceitful.
Maybe so, but I believe there are better ways to communicate your disagreement within an open community. If you have a look at the author’s profile at the bottom of this post you’ll find the mention that you are looking for.
Happy New Year
I updated the article. It was an oversight. People need to chill.
As interesting as your take is, especially on React and all of its faults, you kinda shot yourself in the foot with the clickbait title and not initially mentioning you are the author of the tech that you are praising. In a sense the damage has been done. I'd take this as a learning opportunity.
I'll take the point as a learning opportunity, but it's been in my bio the whole time that I'm the author of RawJS.
Nobody is reading your bio before reading the article. Most people don't care enough about you to even click it at all. They're here for the article and your defense that "it's in my bio" doesn't change anything
Ok bud. You got me. I guess I'm a snake oil salesman. Those MIT-licensed open source libraries with zero profit potential are really raking in the bucks for me.
The fact that you're so defensive about it is proof in itself. You really think people read your bio? Are you reading the author bio of every article you read?
You're projecting your own insecurities on things that are never said. I stated the facts, and that's it.
Have fun using your unproven self written framework in production. The rest of us will be using battle tested libraries for real projects
Hello! I like this very much. I must say, though, that I don't think people will happily embrace it, not to the scale of state-driven frameworks like Svelte or React. Why? Because people don't like it when they have to write code. Sad, but true. People love their JSX and their template-based component files. Hell, I cannot deny how beautiful it is not to think recursively when building DOM's. Having VS Code + Emmet + Svelte extension to help me write HTML is far more appealing that recursion-like calls to create it.
The use of classes you present is very nice: You are reusing DOM elements via containment to make sure none of the DOM complications get out, and work your way around to only expose what you will be needing. It is very nice indeed. Again, the average developer won't like it.
Finally, the last point: State-driven development arose for a very good and strong reason: Simplicity. You are asking the state-driven addicts to leave their drug forever and come back to imperative programming.
Finally, a question: You stated that the object created from the class would have the same lifecycle as the contained DOM element, but I see no code that backs this up. Omission in the examples? Or did I miss something?
A developer colleague of mine recently threw out a Svelte app and rewrote the thing with RawJS because he was so impressed with it. His RawJS version is about the same amount of code as the Svelte version. So at least from that data-point the "its more code" argument didn't hold, assuming the measure is total number of lines.
RawJS has full support for JSX if you want to use it. I probably should have covered that in the article. Though I don't really like JSX so I omitted it.
I think you mean "nested function calls" rather than "recursion". In any event, it's actually less characters to use the nested function calls rather than JSX. And because its just plain-old functions, you get VS Code's intellisense for free.
State-driven development is easy until it's not. That was the point I was hoping to make in the article.
About the lifecycle of the DOM elements... assuming you don't store references around, it would garbage collect. I'm not sure how you would show that other than to just say it.
Hello. It is not the number of lines of code, and it is not the number of characters you type. It is the simplicity of state-driven programming versus imperative programming. People moved to state-driven because nobody liked imperative once you reach a certain point (in application code size). So no, we cannot measure this by lines of code.
Yes, "nested". Apologies, English is not my mother tongue. Sometimes my brain malfunctions.
As stated, I think you have something really nice here, but I don't see how this can compete in the open. This looks very niche to me. For example, from what I read, how would you open and close dialogs? How do you show a validation error conditionally? How do you manage table rows, or list items? It is not obvious, and I fear it will require pretty much all the imperative programming we used to see 20 years ago, before the jQuery era but without the browser differences and a friendlier DOM API.
To be more concrete: Your code samples have no indication of how one should program a
TableRowcomponent that is meant to be dynamically created based on a mutable list of items. Should we add adispose()method of some sort to this and all components to properly remove DOM elements? As far as I can see, RawJS helps in the creation of elements, not in the cleanup of elements. Must I provide this? If yes, why don't RawJS provide, as other libraries do? I don't see the complete lifecycle management here. These and several others are the things that people will miss for sure.Yeah, I would agree there's very few examples here which is a buzz killer. I've built a few different large-scale apps with RawJS so far (one is open source), so I can say first-hand that the stuff you mentioned doesn't create the feeling of pre-jQuery bookkeeping.
There's a simple demo RawJS app here that covers at least some of your concerns:
rawjssample.pages.dev/
(repo)
github.com/squaresapp/rawjs-sample...
I probably should have included that in the article.
Of course this demo app doesn't show how things scale. For that you'd need to see the Squares app source code.
I appreciate this feedback, by the way 👍
Thank you. The world went loopy with JSX. And the current paradigm of functions that produce JSX that has embedded JS that calls functions that output JSX gives me extremely traumatic flashbacks of JSP
Good luck. I'll stick to React.
Edit: read through the article and wonder how anyone could take so many steps back into history. There's a reason for React and other framework's existence. Embrace it.
If you're wondering why anyone would, they wouldn't and they haven't. @paulgordon is the author of the library. His lack of candor in not being forthcoming about that should tell you how seriously anyone should take him. His aim is clearly deception.
Maybe he should have looked inwards when it comes to finding the biggest tool.
Work on your judgement bud. I updated the article to indicate that I'm the author.
Me too. I'm currently learning Next.js and I enjoy it. I must admit, reading this article made me remember the feeling about writing some monolithic apps with RoR. It just feels simple and welcoming. With time I understand the downfall of such simplicity. It lacks the tools you need to quickly inhance the UX. Think of framer-motion, routing capabilities (how else are you going to make routing feels nice 👍), caching, suspense - for skeletons - and content streaming.
Don't get me wrong, I enjoyed reading this article. Keep up the good work 💪💯.
But it's probably wise for me to stick with Next.js.
Dear Paul,
A more direct approach with much less complexity and powerful utilities is the Vulcan. I've working on this since 2012 among other projects.
It's blazingly fast, easy and follows the principle "write less, do more". It has almost no overhead and provides useful tools for everyday web development.
Vulcan is part of micro-MVC framework and is being used by thousands of companies.
Check it out at github.com/g0d/Vulcan
Thousands of companies and 2 stars?
(Actually 3 stars now... I just threw one in the bin)
It' irrelevant. We do not do marketing. We care about the actual business. It delivers and that matters!
Fair enough... but you've got to admit it looks a bit weird.
Check the parent project and see what we also built on top of that github.com/g0d/micro-MVC
Check github.com/g0d/GreyOS
It doesn't get better more awesome I guess ;)
See, this is the kind of stuff that I'd say you need direct DOM access for.
That's why I built Vulcan.js and micro-MVC.... I wouldn't be able to build GreyOS... All the tools that I see in the market are totally useless for that kind of hard work. You can check the performance and stability yourself!
Any documentation? I dont see any
Please check the parent project which includes it as well.
github.com/g0d/micro-MVC
It's fascinating to me how every new "hipster" framework that pops up as of late seems to be doing the exact same thing I've also been working on roughly for the same time as most of these frameworks seem to have been around as well.
Simple libraries that fill the gaps in what the browsers already provide. Instead of adding a new layer of completely new abstractions, that get translated to the browser's model of the website, they just make interacting with this model more ergonomic.
Yep. I couldn't have said it any better. The way I described my own library with a similar aim is that it "aims to be what
document.createElementshould have been. It creates a node, sets classes and attributes, inserts content and attaches event listeners."What's your library? Is it open source? Link it here if so.
It's just barely done at the moment and I haven't used it enough to confidently recommend it for production, and the website is still very much work in progress, but here it is: darkwiiplayer.github.io/skooma-js/
Cool, it seems we're on the same wavelength.
Wait a minute... your propomoting a library called raw js, not just using raw js as in js js?
That's insaine. I'll never use a lib named raw js, next we'll have raw typescript and c, c+, c++, raw c++.net... I know where the word game goes, and the tech world is too big for it these days... waste of time already.
Raw js, what a bunch of tricksters... certainly would trust em with my code... its a 3D online animator, I think I'll call it "raw Adobe flash" lol.
Ok.. so what else should I call it?
(I think your argument would probably hold better if I had called the library "VanillaJS")
Both are bad naming policies, marketing over engineering. But also deceptive, trying to direct true js programmers to it by confusing search. I honestly thoguht you were promoting no lib js. Tbh, I never interpreted vanillaJS to imply raw JS... I interpreted to be the opposite of chocolateJS... so in that regard, maybe the opposite of your intended meaning for RawJS would be CookedJS, ehich is a better and likely more accurate name anyway... just realize, many people have been saying raw js for decades now... I wouldn't be surprised if it turns out to be completely untrademarkable uncopywritable, not saying you would want to... but why eliminate the possibility for deceptive marketing. Cookedjs is better.
Well, somehow I've been in this game for quite a while I'm yet to hear anyone say "raw js" meaning "no framework". I've always just heard "vanilla js" or "vanilla javascript". I tried to pick something that was suggestive of vanilla that wasn't actually "vanilla", and wasn't something dumb like "Unflavoured.js".
Lol, love unflavored... you can't use vanilla already taken. It just it depends whether you like deserts or meat which is better, lol. No frame work, js, raw/vanilla/plain/es6 js all pretty much mean the same to my ears.
In the end, only reason to use someone else's framework is for standardization and speed, without a quantitative analysis proving yours is better in that regard, I just use an existing or built custom when needed... doing that now... crazy company is on bootstrap 2, had to build custom react component framework.
Unflavoured.js is unironically a pretty catchy name
I've been programming for 20 years... I gave up on developers when I came across ANT, Another Neat Tool.
It's nuts... I've only sort of jokingly been trying to convince people we should name our software latin and classify it like they organisms, or physics theories, organs.
I wanna see names where you know what it is just by looking at it, and what similar options exist that overlap with that from someone else.
I.e. a universal ID system.
Too many libs don't play nicely with each other because of this issue, and too many companies end up in a partial migration state... ive seen react and angular in the same app... built with web pack.
Like for God sakes dudes, lol. I mean, I'm an engineer, when I need a ball valve I got 50 vendors I could go to, but they don't call it "another neat widget" or "maven the raven" or "gradle the... mavel?"... 😆 🤣.
I guess I'm always science over marketing... and naming is import in science. "To name a thing is everything, to name a thing is to truly know it". God help us on component naming.
I embrace the idea of using native js, and the DOM API more. At the same time, I also like to use MARKUP for my documents, not javascript. If I can't have some templating that looks like jsx/php/jsp/etc, where I can also just inline plain vanilla HTML as I please, I just won't buy it, I'm afraid.
Interestingly enough, it looks like the quite opposite of the idea brought forth in this blog post, is the html-first principles, which shy away from JS, and use HTML attributes for dynamic behaviour. With the help of a JS library of course, named htmx.
I think RawJS and htmx are two extremes, where the ideal is in a middle ground: Give me access to the DOM API and all the other nifty web APIs modern browsers provide (which RawJS provides, but html-first rips away). But also, give me a HTML-like templating language, to describe my documents (which RawJS shreads to pieces).
PS: First thing I find when searching RawJS is a library that tries to replace lodash and moment.
RawJS supports JSX. Use it if that's your thing. I just don't like it myself. And I've found that more people dislike JSX than not.
My thing is writing documents with a template language. If I can write pure HTML that would be even better.
I'm really intrigued by your proposal and strongly support a paradigm shift towards more lightweight approaches.
However, your response to the criticism you received regarding the misleading tone of the article is a bit disappointing and distracts from what could have been a great contribution.
Chill out man. ;)
Since you're the author of all the concepts here, maybe mentioning it would make this article sounds less... apocalyptic. Also, the name of your library is already taken vbrajon.github.io/rawjs/.
I like the ideas you bring though, they start a not-that-new discussion still needed in the myriad of frameworks we have.
Article was updated. It was an oversight.
Picking a name is really hard.
Basically everything is taken.
Name it after my gf and you'll be fine.
Thanks for this write up. I know it’s a lot of work, and based on the comments I think this article is very poignant
This library helps to smooth some of the rough edges around vanilla js, which is cool. It is reminiscent of jquery, which I used heavily about 10 years ago. As mentioned in the comments, the problem comes down to data binding.
Say I have a simple collaborative app, like something for doing sprint retros. People’s names are all over the place. Then someone changes their name. Now what? Without a reactive framework I have to find and update that name everywhere. And as you go, you’ll find many cases like that. Adopt all the design patterns you want, the problem won’t go away
End result, you find and fix bugs for quite some time until the application is stable. And because it’s so hard, you resist changing the app, which is the first step towards death
Reactive frameworks were built to fix this problem. And they do. Bugs are few and far between and the application is easy to evolve. Sure, it’s not hard to let things get bloated and slow, but a few best practices can help with that
There is a time and place for reactive frameworks and I don’t think people should reach for them by default. But I would advise someone to be very careful about choosing vanilla-ish frameworks for their project, especially if they plan on growing the application
HatJS solves this, and I'm sure there are other libraries that do similar things. HatJS has a pub-sub style messaging system in it to broadcast events to components that subscribe to handle the situations like this. I didn't include that in the article. From my experience this is has been more of an edge case (not that the name isn't all over the place, but that it's all over the place at the same time before the component gets re-rendered), so I decided to omit it from the article.
You wrote HatJS, too, didn't you? Your profile says you invented the "Squares app," and HatJS is in a repo under an organization by the same name.
Just realized Paul Gordon invented RawJS.
Still very interesting though. Never a big fan of React even though used it at work.
By the way the fact that the author of the article is the author of the library is stated in his bio: "Inventor of Squares (the app), Webfeeds (the protocol), StrawJS (static site generator) & RawJS (React killer). I build things you need, then talk about it." This bio is very visible on PC version of dev.to but not visible on mobile version.
Thank you Charles for being rational about this stuff. People are losing their sh!t over some silly oversight, and I edited the article anyway.
Hey Paul,
Your article is fine and the edit is enough, no need to rewrite (maybe a FAQ blog post would be better since I see a lot of discussion/questions in the comments :3 ).
Anyway, it's not the first time I've seen an author talk about something they created as if they just found it here on dev (it's quite common) but, the main issue I've seen when articles like yours become "viral" is that they compare themselves to a technology/framework (and "puts it down") and that causes a BSOD in the minds of many users. Especially if said technology is popular, has an almost cult-like following or is PHP (that had to be the most embarrassing angry mob event here in dev because the article was obviously written for a company blog as marketing).
Keep up the good work and continue causing chaos here in dev, some of the authors I saw who had this issue/canon event decided to leave and it be a shame if this happened again.
Hi Pandita
I agree... I'm not going to write an article like this again, I'm going to be more careful next time. I blew 2 days putting out fires and trying to calm everyone down. Sure it went viral (it was home page of HN for a bit), but in no way was it worth it. Not even a little. Maybe if I was selling something it would have been.
I hope you have success with this project. I'm not sure what scale of application it can handle without adding a lot more dependencies anyway, but hopefully it fares well.
I did at first think this was about something you discovered, but with your edits, I can see that you've clarified a lot after all the backlash. Unfortunately, I initially read this with a kind of "I've been doing something wrong" attitude; maybe that's some degree of impostor syndrome I have.
It looks like you've found a way to build some apps without tooling like React/Angular etc., and I can imagine it works well for some projects. If I'm hanging a photo, I just need a hammer and a nail. But those frameworks were, after all, founded to solve a common problem, and they do so effectively. If I'm building a house from scratch, I'm not sure one single hammer is going to suffice.
I maintain two very large-scale Angular apps. One benefit to Angular is there are really useful component libraries built on top of it, such as PrimeNG and Angular-Material. They're pretty good at what they do, and it saves my team from reinventing the wheel. If I need an extremely complex and dynamic data table -- with varying, sortable, re-orderable columns; expandable rows, pagination, filtration; editability, and even an export to CSV function -- either one has got all that built-in, and probably more.
"I'm not sure what scale of application it can handle without adding a lot more dependencies anyway"
I generally vote for adding complexity / dependencies as the project grows rather than defaulting to a base of complexity that may or may not pulling its weight. I tend to custom build more often than the average dev in order to get something that fits just right.
It's the craftsman approach rather than the factory approach. That might sound like a flex, but it isn't necessarily. The craftsman approach isn't always good. Perfectionism can ruin projects.
"Very large-scale" sounds like you're building high-rises rather than houses. I'm overseeing a vanilla JS/TS project right now which would be at a scale beyond hanging a picture (i.e. a one-man hobby project).
I think the point of the article that perhaps didn't come through was to be less about pointing fingers at specific individuals and saying "you are doing it wrong", but rather to take a step back and take a first-principles look at what has happened, and question if there was a better way all along. I didn't intend to incite developers to set 15+ years of component libraries and other surrounding infrastructure on fire 😂
Fair points; I suppose adding stuff as it grows is indeed a good approach! I do tend to start with vanilla on personal projects nowadays. I've even employed your approach of "DOM = source of truth", but I'd only done that in "throwaway" projects and I'd only heard of people cringing at that until reading this article. :)
I haven't coded on the side or started any projects in a while though. The ones I was thinking of had a big scale from the get-go, were funded upfront, and were both initially created with Angular 2 long before my employment here haha. One of them is [basically] a huge monolithic custom-commissioned intranet app that has a ton of inter-dependent tools in it.
Anyway, haha, I do see your point, and I admire your effort to think about stuff like this in the first place. For me, I've lost most of my interest in coding. I prefer not to spend time thinking about it. I guess I'm in the infamous "comfort zone". Though to be fair, you did end the post with "So, have I convinced you to set your React app on fire?" 😂
Anyway, I think you're onto something, and it sounds like your library could already be compatible with certain libraries anyway. I imagine there's a tailwind components library out there, for instance. (Haven't ever used it)
Yeah, RawJS actually works quite well with Tailwind given how Raw.Param interprets strings as class names. (The vanilla project I'm overseeing went tailwind + RawJS).
Very interesting post, I love it while fully understanding that you made RawJS. I may have found a typo in your website, by the way:
And below that:
Should be?
And perhaps this:
Could be:
Just some minor typos. I also noticed that your site has no title or favicon. Might add those. :)
Overall, very fascinating concept and ideas. I followed your X (Twitter) account.
Have a nice day!
Hey, thanks for that! Honestly, I wasn't really expecting this article to even go anywhere, but it blew up out of nowhere after I accidentally hit the "publish" button, couldn't find a way to unpublish, then a bunch of people and a few trolls started accusing me of basically being a snake-oil salesman (??). Strange day today.
The Squares website is still half-finished, as is the app (it's still on private TestFlight for iOS and hasn't been pushed to the iOS app store yet). It's totally not ready for prime-time yet. But I'll get these typos fixed!
Awesome! I'll be following your project to see how it develops. Let me know when you make advancements; I followed you on X and here to get notifications.
P.S. To unshare a post, go to dev.to/dashboard, click on the “Manage” button of the post, and use the delete or archive option on that page.
It's an odd world, and marketing something you wrote is fine and you'd have got away with it 90% of the time. I admit I liked the article, but was surprised when I flicked my eyes up to your bio and saw you were the author of RawJS - didn't make me feel like I wanted to remove my heart reaction or my moderator upvote, but I thought - oh that's a ballsy way of going about it that does cool my warmth to the content and the angle portrayed.
It looks like an interesting project and I don't think you deserved the intensity of the pile-on that followed, but the algorithm here does promote content with lots of comments and reactions. I think I learned something about article writing from your experience, I've had my fair share of flaming comments from fans of one style, framework or whatever - perhaps the way in which you couched this article was a bit like dousing yourself in gas to start with. I didn't guess that from my reading of it, but seems like it was the outcome.
I'm looking forward to reading more of your stuff and checking out RawJS.
I think everything has been already said by the other commenters, so let me just add that a while back, a client of mine was facing the same dilema - should we write the UI in Vanilla or use a framework? I created a repo vanilla-vs-framework where I wrote the same app in React, Angular, Web Components and HTML templates to demonstrate the practicality and performance differences.
You can be the judge of which version makes more sense. Disclaimer, even when using purely the DOM apis I still tried to go in the direction of declarative templates, since these imo make the most sense for most developers. Also, while you might prefer different architecture or coding style, it still should give you a pretty good idea of what it means creating UI without any mainstream framework.
I'm honestly encouraging this person to work on their judgement, because it was off in this case. There is no harm meant.
Having said that, I hope you can understand what it feels like to work on something for over a year, release it to the public for very little reason other than to offer it to the community, then a mob of trolls come in and trash me because I accidentally left out from the main article (but not the bio) that I'm the author of the library.
I'll be on a podcast tomorrow where I'm going to touch on how my entire life has been dedicated to charity. I'll send you the link to the show if you'd like.
Work on your social skills, bud.
Appending "bud" at the end of a sentence is usually perceived as quite condescending. There was no harm meant, sure, but it came across that way. That's the point.
And does it mean nothing to you that there are so many comments by people who read your article and felt like you were trying to hide the fact that you're the creator of RawJS? Even if your intentions were honest, it just comes across as a salesman trying to sell snake oil.
Add on to that fact that you're doubling down and not even addressing valid criticisms of one such commentator in this post by remarking "tell me without telling me you simply don't know how to build a well-organized vanilla JavaScript app"... yeah, you're not helping yourself with such statements after the comment delved into details about why they disagree with your "micro-library".
The commenter you're referring to came out of the gate being quite rude and dismissive. People with that tone aren't interested in fruitful discussion, but rather in proving themselves right, usually at other's expense. I'm happy to respond to comments in the form "Interesting idea... but how would you handle situation X?"
Please do post it
a long row of JS "frameworks"...
The HTML-DOM-API makes it super easy to build the DOM directly, so there are quite a lot projects (I suppose more than 100) on GitHub using this approach, RawJS is by far not uniqe. The most compact approach to DOM creation I have seen is used by VanJS. If you remove all code that implements the state logic of VanJS, the whole library can be broken down to a single function See also here:
Now you can create all HTML-tags directly through JS-functions. My own library DML has more a focus on "writing less code", so you can implement a list in the traditional way, or just write ol(["Item1","Item2","Item3"]). Unlike VanJS, DML directly append elements to the DOM, which gives you a HTML-like experience in Javascript. But DML does not implement a state logic at all, it just encourages people to build event based reactivitiy.
Finally it comes out, you can build nice web applications with most of the frameworks. They might not serve to build a new amazon home page, but for some projects they might be a good or even the best solution. It would be super interesting to make a comparison of all the different approaches used, I suppose there are a lot of similarities:
Unfortunately, there is currently no project that has developed enough traction to attract and combine all of these efforts. If we ignore the often minor differences, we can ask:
Does this make any sense to build on the DOM directly?
In short terms: Yes. The Direct Dom Approach has some advantages:
Browser compatibility is usually not problem anymore, if you avoid the latest features and stick to a ES-state 2-3 years back, your code will run on 99% of all machines.
And there are some real advantages over the traditional HTML/CSS-approach:
So, there are quite some advantages, but I can also understand people that rely more on proven frameworks and toolsets.
What do you do on the web...
Finally, it depends much on your task, which approach serves best. For traditional web design, I suppose, frameworks like React give you the better ecosystem. But to build interactive and higly innovative web-applications, the Direct Dom Approach can be an interesting option.
The author meant absolutely no deception beyond just providing an exciting title to get people to read about a library/tech he created. Click-bait would imply a falsehood. 'After creating RawJS, I'm never touching React again'. No false claim there.
While I find react and other frameworks to be remarkable pieces of work and use them daily, I'm always looking for something 'lighter' and more transparent. I despise black boxes.
This author has put a lot of time and effort into RawJS and wants to see it succeed. Is he passionate and emotional about it? Sure. Who wouldn't be.
From what I can tell he's tried to be respectful, but with all the negativity it would be difficult for anyone.
If you've tried the library and like it great. If you don't like it, that's okay too. If you like the heavy frameworks, great. You're not stupid for liking them. But honestly, give something like this a try. It can't hurt to expand horizons.
The article title used to be different - "creating" was a different verb, I don't remember which one, but something more along the lines of discovering. He edited it after the backlash.
The old title was "After using RawJS..."
I understand why some people thought it was deceptive, and so I changed the article title after one commenter convinced me that it would be a good faith gesture. But I had no ill intentions.
OK yeah, that's not as bad as I remembered.
Hey, I like what you are doing with RawJS. It is similar to a personal library I made. I cannot really speak to the scale of it yet, but I enjoy programming with it more than any other JS framework (and I love react).
Here is an example website I built with it: ui-lib-example.web.app/ I would love to hear your thoughts about it, if you have some time.
I like what you''re doing here. Its quite similar to RawJS.
It doesn't seem like it handles event subscriptions though? That's major.
Also, RawJS interprets strings as class names rather than text content, where as raw text content needs new Text() or raw.text(..).
This was a fairly big non-obvious revelation to me when I realized that this is actually what you seem to want most of the time.
Oh thats interesting, why is that? Just to help the dev add class names quickly?
What do you mean by even subscriptions? you can set handlers for
onclicketc in this way:Oh yours does events? I didn't catch that. In RawJS, the event subscriptions are "portable". To write it out in long-form:
Basically, events are created as Raw.Event instances, and when you pass a Raw.Event object to one of the element creator functions, it binds the event to the object at that time.
The benefit of this is that you can now encapsulate the construction of events in functions, and have functions return unattached events that then get installed on whatever object calls them in the function:
Adds a
<div class="this-is-a-class">to the DOM with a click event attached.Its hard to describe how powerful this is to be able to encapsulate complex element constructions into callable, reusable functions. I don't think my article really did justice to this.
Oh I see what you mean!
raw.on(...)is a really good ideaIs the library open source? If so, link it here.
Here you are: github.com/eaallen/ui_lib
Hello Elijah,
is there any place to download your lib?
github.com/eaallen/ui_lib/blob/mai...
Maybe you take a look on VanJS, seems to have a similar approach.
I have not heard of VanJS until today, but it does look almost exactly the same! And here I thought I was clever.
Oh but I'll add the state management looks much more sophisticated than what I have done. I don't really have a state driven events, you have to explicitly update. Which I know could be a pain, but I have not had any headaches yet.
I adopted some routines from VanJS to my own lib DML, specially the ingenious tag-routine, but beside the same naming conventions the core was too different to join. DML does not have a state management too, but I never missed it. State management gives another layer of invisible connections that may be handy, but is also limited to very basic connections. Any state change has a reason, so we can also fire an event when the reason occurs. This is a different thinking, but is more explicit.
That was somewhat of my thinking too. Explicitly "re rendering" the UI that needs to get updated has worked well for me so far
Thank you for the article. The real issue is that most "frontend developers" don't realize how easy DOM APIs actually are. A real frontend engineer has no problem working in a completely Native JavaScript environment. In fact, in many cases it is easier not to fight the framework and, like you said, take a scalpel to different areas where precision is necessary for performance gains. So, if we're talking "raw", here's all you really get from using a render engine library like React or those parts of an actual framework like Angular or Svelte:
Number 1, 3 and 4 are actually extremely easy to do and number 5 is almost irrelevant depending on how you put your app together. Number 4 is less relevant or irrelevant if using a pattern. And, btw, I'm not even talking about using the Web Components / Custom Elements API(s). So all we're really talking about here is #2. Databinding is kinda nice a lot of times but the real need is actually just a convenient way to pipe the data from some scope into the appropriate elements. Otherwise, it is really just a matter of creating scaffolding for developers, namely juniors, to aid composition & organization of modules.
That being said, you need to have some sort of application head and a head for any part of your app with relatively high complexity. That head should, ideally, be a module that implements The Façade Pattern alongside a Mediator with a "Store". The Mediator can even be (or start out as) nothing more than an Event Bus or PubSub pattern. The "store" need be nothing more than an Object Literal or Dictionary. The advantage to this is that each module simply uses the API provided by the Façade and the Mediator has a high level view of the app's state so that it can have the smarts and direct interaction between all of the, now very dumb (and portable), components. Dumb is a misnomer because they're actually very chatty, allowing the Mediator visibility over the conversation between modules and invoke the right ones at the right times.
All in all, I agree with the author about most of the article. Generally, you just don't need a framework much if you know how to put an app together. In fact, the biggest change I've seen from The Great Framework Wars is a dumbing down of juniors and developers in general. Much of what any framework or library does is encapsulate a single, simple pattern and say "use me because I'm magic and you should be afraid of doing anything yourself". That's poppycock. I'm here to tell you can, and should, have much more faith in yourself. Just remember, these frameworks have armies of marketers behind them and they, just like a car salesman, want you terrified not to buy their product.
"the biggest change I've seen from The Great Framework Wars is a dumbing down of juniors and developers in general. Much of what any framework or library does is encapsulate a single, simple pattern and say "use me because I'm magic and you should be afraid of doing anything yourself". That's poppycock. I'm here to tell you can, and should, have much more faith in yourself."
Preach!!
With respect to your previous point requiring a mediator / facade--the previous mobile app that I built uses something like this (though not quite how you described). I could have included some more high-level architectural stuff in the article, but I didn't want it to turn into a book. Future posts to come.
I like what you have done. I'm always excited about ways to solve the issues we use frameworks for in vanilla. My question is the DOM to house data models thingy. I'm not sure if I understand 100% but that sounds crazy to me. I want my data to be data - objects, arrays, primitives, not HTML attributes. That's like something I would highly, highly discourage, and get very, very miffed about. Again, not entirely sure, I may have misunderstood. Ok so how would you work with the data? To store anything more than primitives would you need DOM elements in the same data structure configuration as your data model, 1 to 1? I agree that DOM manip can be good for clearing the overhead of virtual DOM diffing and things of that nature and appreciate a hands on approach, but it seems like the overhead of reading state out of the DOM in order to work with it would be a very major performance consideration here?
Well, if you had told me 1 year ago "just store state in the DOM", I would have had the same allergic reaction.
The basic pattern I've been following looks like this: make the constructor to the class accept some input data (such as, something that came from a database). Populate the view with all that data. Say it's a user profile or something with bunch of different input fields. Then, have a save() method in the class that gets called on some event (like the save button being clicked) that just reads the .value property from all the HTMLInputElement instances you've got. It would then construct probably some JSON object, and ship this off to wherever it needs to go to get saved.
Binding to a list works the same way. Take the array as an argument, create a bunch of ListItemComponent (or whatever you decide to call it). Then add them all to the DOM, add support for deletion and moving up/down if necessary, all done at the DOM level. Then when its time to save, read the DOM rows (which probably need to be ACC's), read their data (probably with some getter functions) construct your object, and send off the data. (Of course this doesn't work if the list is massive and needs to be buffered). It probably sounds more complicated than it actually is. I might need some full examples to fully articulate.
Some apps will be doing these same thing in a bunch of places. I've found it pretty easy to generalize these kinds of things into function calls. RawJS's high composability makes this a lot nicer, too.
There shouldn't be any performance issue with reading data out of the DOM (unless its a .offsetWidth access or one of those properties that trigger a reflow).
It doesn't sound complicated - data comes in to the DOM via constructor or otherwise, data exits the DOM via a save function that traverses, reads, outputs data. Its def all you need if we're talking about a purely GUI data model where the shape of the data lines up with the shape of the DOM. My response was really because in your article you're addressing the overall 'data structure which is deemed to be your "source of truth"' in order to 'build apps', which to me means quite a bit more than just the data models for your GUI, right? Obviously, your instinct to avoid divergent models of what is supposed to be singular data is correct. I'm just thinking I guess about the data model for your 'app', application state, etc., as encompassing more than the data that directly will inflate your UI. Anyways, its a cool thing you've built with some useful bits in there. I'll give it a shot on some demo components and see how I fare.
"My response was really because in your article you're addressing the overall 'data structure which is deemed to be your "source of truth"' in order to 'build apps', which to me means quite a bit more than just the data models for your GUI, right?"
Parts of the article probably need some clarification, but I think you've got it. Using the DOM as your state manager basically means: store the local state of a component... locally in the part of the DOM that that component manages. This way you can drop out the complexity of having some state manager and/or local state<->DOM sync, but it also cuts down on scenarios where framework-supplied reactivity would be necessary.
Try this - implement a simple reusable data grid with data rows, columns, data binding and column value types. Sorting, grouping, row filter.
First, using RawJS, then using Angular (sorry, I'm not a React guy). Compare performance and maintainability.
Angular provides the abstraction from render, so you mostly don't need to think about it in terms of markup. Instead, you either don't think about it at all, or think about it in terms of your own components, and forget the impl details. This point will become clear once you start implementing a moderately complex app, framework or component. Also unit testing can be done effectively with this approach.
If you are wondering about LOC example, it's anywhere in 100k-1M of frontend code, where consumers are business clients. Meaning that instead of a login form with 3 fields and 2 screens with 10 fields (typical consumer facing app), there are hundreds of screens with hundreds of forms each, data grids, parent/child, tabs, menus/submenus, user/group permissions with proper inheritance, with extremely complex and dynamic form validation, dynamic fields etc. Which all needs to happen instantly. And be able to quickly fix a critical bug in minutes, ideally.
I can see a data-grid comparison example being quite descriptive.
Though I think in any real-world scenario you'd be reaching for a fully fleshed out data grid library in order to handle the scenario you described.
I'm sure there are a few different data grid libraries out there that are built on vanilla JavaScript. And there are certainly lots that use React.
So in effect, would you not just be comparing one random data grid library to another?
I don't think a toy-example data grid library I write in an evening is going to compete with something written by a team of devs over the course of numerous months, regardless of the underlying technology.
The point is to show and see how we can manage complexity in a relatively small but coherent app. It's difficult to explain how to build a small enterprise app to someone who never built one. It is easy to explain to anyone what a data grid is.
Whether you'll build a new data grid or use existing depends on project budget and its performance requirements. Sometimes you need that 5x boost and you can afford to spend a million dollars to build one for company's internal use. Especially considering that each dev license can be 500-1k per year. So even with a few hundred developers it pays off in a few years. And you get much quicker bug/feature turnaround.
Thanks, nice concepts, specially the auto garbage collected wrapper to elements, although, doesn't a web components do that too?
I prefer to read html for the markup, css for styles, and js for the rest. Browsers prefer it that way, and probably you too as a user, specially on slow connections.
For small WebApps, I find the most fun and satisfaction when working with the platform first. Is also then so easy for others to collaborate... :)
"doesn't a web components do that too?"
They do. My problem with web components is that they require registration, and inheriting from HTMLElement makes your components have a less flattering intellisense experience in the IDE (because web components inherit a million members).
I find with the ACC pattern you can just
element.append(new MyComponent().head)instead of the marginally shorterelement.append(new MyComponent()).My main problem with separating HTML out from CSS and out from JavaScript is that your HTML and CSS become overly static ("unprogrammable", if that's a word), and it also can complicate bundling / deployment. It's easier to just ship one JS file and be done with it.
My rules when I code in js:
In fact the class theory that was a big hit back in 90s with all it's literature, hierarchies, properties etc. proved a big fiasco in life as "things of this world are more collections of attributes than strict hierarchies based on inheritance".
Back in 2015 I started following that rules and nothing convinced me for the opposite.
The frameworks with all their bloated approaches and theory never reassure me that they have sth useful to deliver in code development on the contrary they are responsible for the
In fact frameworks were used as an economic tool so that money can change hands! They have a hidden economic use and not a technical one as many believe.
Yes, frameworks contain a set of tools and connected libraries that help people build code faster but we have to question the American policy:
This is beyond the scope of this article, but your comment was interesting so--
Technically, you're functionally correct that reality is composed of amorphous blobs of "stuff", and there is of course a strong case to be made that code should align with reality.
The problem that myself and others (most?) tend to see with these kinds of approaches is that when you completely disband the notion of classes, your grouping mechanisms begin to deteriorate. Human cognition naturally organizes reality in terms of IS-A and HAS-A. These are constructions of the mind that don't technically exist, but when they're gone, you in effect lose your ability to point at something and say "that's a cat" or "that's a potato". So your code gets harder to reason about. The degree to which this happens would be different depending on what the code is actually doing.
Of course, you can go full-on "architecture astronaut" and end up with the problems you described. But I don't think you can use the exception to draw the rule. The majority of the application code in the wild is class-based.
The problem I see with react is you can't attack the DOM from the side, or any other angle, except from above. And then there's all the overhead mentioned wity a virutal dom, etc. This is foul imo. Happy to stick with innerHTML (or explicit insert/remove element api) for once in a while dom updates, and simple selector/class/ID queries. Also, when I need to, weak references - where unique ownership of a dom element (in the pattern this article highlights) is not possible.
Thank for your comments. I believe at this point I have done everything a person could have reasonably done in the case when an article that was written with pure intentions wasn't received by all in such a way.
Now let's steer the conversation towards productive ideation around different ways to dodge complexity and gain control. 👍💪
Interesting approach!
How would you recommend dealing with server-rendered markup, such as a todo list with 3 prerendered items? Your examples mostly show element creation, but what if the elements already exist?
I can think of a few ways to handle that but it seems like a lot of work to support both prerendered markup and dynamic creation, unless I’m missing something?
No, you're not missing anything.
If the elements already exist, we're venturing over into a very different architectural style and a use-case that RawJS doesn't really address, at least not yet. Another hydration layer would need to be placed over RawJS in order to support this. I know how this would be built, but to be honest, my general take on server-side rendering is that it's too often a premature optimization.
Years ago, I was an architectural consultant for a very large media company where every millisecond of slow down resulted in damages to ad revenue. This situation most definitely required SSR.
For other cases though, especially those that are firmly conceptual "web apps" rather than "web sites", I think the cleanest architectural style is the dynamically constructed thick client + API server design. This way the separation of concerns is on-point and you don't have this awkward semi-bifurcation where the UI happens both within the browser and within the server.
:) Really love the article. Thanks for posting 🙏
I love RawJS and had no idea it was you! Great!
Thanks Griff 👍. I'm available on Twitter (at)heropaulg and I'm always open to chatting.
Thanks :) I might be in touch soon!
You are talking about complexity, but offering an example that had 10x more lines of code for doing the same thing. Complexity in most cases is the amount of code, and this is what all the frameworks want to achieve, make it less code.
Not necessarily make it less code, but make code declarative, so other developers can better understand what a line of code is doing, without having to build an increasingly large mental model of the program in your head.
I'm honestly having trouble understanding this argument. Both myself and the developers I'm working with on RawJS apps find it way easier to see what's going on if there isn't some framework doing a bunch of weird magic for you behind the scenes, not to mention gaining the ability to step-debug the code.
There's always something doing magic unless you have the mental capability to understand pure binary.
It is also easy to see what is going on in React. It actually does surprisingly little magic, once you learn about a few key concepts like the vdom and the render cycle.
RawJS setup is extremely simple, but it doesn't offer any solutions to common problems experienced when building enterprise applications like state management and reducing the number of DOM updates. You're basically going back to the before days with jQuery when we realized that doing so many DOM manipulations at once, made our apps really slow and we had to start writing all kinds of optimizations that made our code really hard to reason about.
There's something to be said about going back to basics to avoid the bloat. There's also not knowing what the frameworks are doing behind the scenes. I've been using "raw" JavaScript to develop PeerScript.com to avoid introducing unexpected privacy and security issues from frameworks especially when interacting with blockchain-based APIs. I'll check out RawJS to learn and experiment. Thanks for the article and for triggering ideas.
Hey Paul, thank you for writing this. I also watched your talk at TorontoJS. I was wondering whether you have any opinions on how this approach you advocate for compares to qwik. Would love to hear your thoughts
Thank you!
Greetings Alessandro!
I haven't worked with Qwik so I can't really give good insight, but from what I can tell it's a layer on top of React?
It comes down to this–do you want a heavy framework with tons of opinions that accelerates a very specific kind of app organization structure? Or do you want something that gets out of your way, gives you more freedom, but ultimately makes you more responsible? There are advantages either way.
HTML and CSS were designed from the get-go to support mostly-static scenarios. Stuff that is more on the "web site" end of the spectrum rather than the "web app" end of the spectrum.
For the last 20 years the standards bodied have been shoe-horning this to make it work with dynamic situations. If the web of the 90's was an app platform first and site platform second, I can't imagine it would have looked the way that it does.
Svelte certainly "seems" easier--until you learn how to build things yourself. Then it just seems like training wheels that serve a questionable purpose. At least this has been my experience and the experience of the Svelte die-hards that I've converted to vanilla.
All frameworks are great timesaver, when you have to do standard stuff, and are a disaster if not. This has been true since the dawn of comp science.
Thanks for the write up, Paul! I love different ways of thinking or approaching coding/design even if they may not fit a current project. This is a very interesting take!
I love this and I have always been a fan of vanilla js, unfortunately the framework issue affects end users severely and they have no control over the situation.
Can you expand on what you mean here? What framework issue do you see that affects end users?
Title should read "After creating RawJs..."
Yeah I updated the article. Honestly the problem is that I've been using RawJS for so long now that it looks like the name of a library to me rather than a concept (to me, if I had called this library "VanillaJS", I would agree with all the haters here accusing me of being disingenuous)
Until you update the title I doubt many people will lay off the vitriol. Do you honestly think that “After using X I’m never going back!” could possibly imply that the author is the creator? It’s just totally irrational. You seem like a genuine person and you’ve definitely made some improvements like the edits at the beginning of the article, but the title really says it all and I think that will be the litmus test here. As I read through the previous comments I saw a number of sensible titles suggested FWIW.
I disagree.
Look at the most recent comment: "This author is so unhinged. In 23 years if web development, I've rarely seen somebody who knew so little make such big claims."
Nothing other than a complete re-write of the article is going to fix this troubled individual.
I'm probably going to just lock the discussion and try again. People can't control themselves. Anger generation for clicks is literally what the open-source "Squares" app that I'm working on is trying to fix.
You are right that some people are just trolls and it won't matter. But for the significant portion of people who are commenting in good faith, your continued refusal to change the title of the post, i.e. the only thing people see when it shows up in as a recommended read, or in someone's inbox, etc, belies your other efforts to "come clean". The title's phrasing cannot reasonably be interpreted in any way other than an attempt to generate excitement about something other than one's own creation.
Title changed.
Kudos! Appreciate your good faith
This kind of made me fall in love with JS after years and years of avoiding it because of what I think is unnecesary complexity. That being said, a disclaimer would've been nice!
Thanks for the read! I added a disclaimer after waking up this morning to a flame-war.
So you argue that using plain JS to create HTML template is preferable to using a special purpose language like:
JSX, Handlebars, Glimmer, Mako, JSP, etc, etc.
I don't find this convincing.
In the backend, people quickly created template languages to use (basically, DSLs for generating HTML).
And that's all that the JS based frameworks are: DSLs for building DOM.
Once you accept that you want to use a template then you have the issue of "data binding", i.e, how do I pass state to the template, update the template when state is changed, and so on.
Even if we store the state in the DOM, we would still want a way to ergonomically get that state out of the DOM and into variables so that we can perform logic.
The idea of this framework is IMO absolutely inappropriate for any large application. The best pattern regardless of framework is:
That said, I do believe that there is a lot of needless complexity and questionable practices in common UI frameworks. But the answer isn't RawJS.
A lot of people dislike JSX, and there is a huge rise in CSS-within-JS solutions because there seems to be a mass of people that like the programmability that comes with putting everything in JS.
The way how I've addressed this is with getters / setters. It has worked quite well and leads to obvious code that is easily debuggable.
I suppose things are different if you have to manage a large team with many developers that work on the same project. Dealing with state transitions gets challenging. React removes the need to care for state changes at all, just build the next state and let the virtual DOM do the Job. Or in other words: React allows teams to build bad websites that look finally acceptable. If you are not Marc Zuckerberg, maybe your preferences are different...
"React allows teams to build bad websites that look finally acceptable"
I agree with this statement 1000%. I think that is the true selling point of React that nobody wants to admit.
Careless defecation of state into a VDOM leads to "magic" code that becomes hard to debug as the application gets big, and especially as developers move on and off projects. I recently had to throw out a massive (inherited) React project that was the worst example of this. It was impossible to figure out what it was doing. The code base was rendered useless after 2 team transfers. With a RawJS app, you'd at least be able to follow the spaghetti written by shitty devs 🤣.
There is another reason why React uses a VDom. React - at it´s core - is stateless, but the DOM is not. Making a stateful system stateless is pure overhead. And the DOM can handle state transitions pretty well,...
I don't even love React, but if this is the solution I'll stick with it.
I've never liked using classes in JS and you talk about the verbosity of React only to write giant classes with constructors and 2x as much code for the equivalent React component.
You also talk about how RawJS is the solution....but it also needs HatJS and a third library to do what you want it to.
The "ACC Pattern" is...ugly, verbose and feels more complex than React lifecycle methods. I've never had to care about when things are garbage collected in my 6 years of professional web dev work and I've worked on some complex projects.
"The "ACC Pattern" is...ugly, verbose and feels more complex than React lifecycle methods."
It really isn't. "Feels" is not a substitute for actual experience working with this technique.
You're falling into the trap of comparing toy example in framework A with toy example with framework B and thinking that that is representative of
From the RawJS website: "Don't be seduced by demos of data-binding done with a few keystrokes less than last years framework. Excessive focus on optimizing for code length (especially in toy examples) often risks de-optimizing for actual time drains."
It's not just about code length - it's about the repetition and structure as well as using classes which are very uncommon in the modern web dev ecosystem.
Declarative and functional programming is much easier to reason around when you don't have an OOP background. I don't want to have to care about readonly, public, static, super, constructors, etc etc etc - and my successful career has proven that I don't have to.
I know this is your pet project, but none of the examples you provided convinced me that this is a better way and not disclosing that this is your project is weird.
That sort of "revelations" always look to me like a marveling about how much easier it is to add up seven for six times to calculate 7x6, instead of using "overly complicated" concept of multiplication.
In what way are these classes anonymous? You've just put a new name for something that already has a name, "class".
There's nothing inherently anonymous about writing a class around managing (a) dom element(s).
It's a misleading term for the language. Anonymous functions are functions without a name. Anonymous classes are classes without a name, which are heavily looked down upon
Anonymous classes are usually associated with a cluster. Your example are not anonymous
Congrats on the ability to simplify things and kind of coming back to the roots. I don't see imperative DOM manipulation as the future though. E.g. Manipulating lists this way requires unnecessary complexity. And if you wanted to do it right you'd probably ended up using
templates and some helper functions. IMO if you want to become any modern framework lighter alternative, you'd need to provide some control flow helpers. And even then, your target wouldn't be React enthusiasts but rather developers who'd rather stick with jQuery.I don't disagree with a lot of your points here, I'm really frustrated by the sort of monolithic frameworks that get used for practically everything these days. However, I also don't think that direct DOM manipulation is practical beyond a small scale. And that's not because it's difficult to do, but because it's hard to maintain.
The reason that HTML works well, is that it's just markup. A human can read it and and understand the structure pretty easily. Building a page with nothing but procedural JS is simply never going to be as easy to understand 6 months, a year, down the line when you or someone else needs to make changes. While basically any system that uses markup or templates will be far simpler.
As such, I think the goal of "RawJS" as a wrapper around the DOM API as a replacement for frameworks is short sighted. There are other, systems like lit-html that provide a lighter means of templating without dropping the concept completely.
Furthermore, I do agree that maintaining a whole source of truth for the entire application state that is separate from the DOM isn't the best choice. But I don't think that means we should try to offload all state onto the DOM. I don't like Virtual DOM, I think that's a bridge too far, but some of the application state is going to make more sense as objects in your application rather than data on the DOM. And one reason for this is that most complex applications aren't going to be fully front-end only affairs. As soon as you need to make an API call, you are dealing with data that's not HTML. You need to then take that data in, and figure out what to do with it, before updating the UI.
If you have to keep dipping into the DOM to see what the application state is that's just... silly.
Finally, the elephant in the room: I read the article knowing you were the author of the library. And I still came away with an uneasy feeling about it. Furthermore, seeing all the comments on this post a few things are clear to me:
Ok, so I've updated the EDIT 🤣
So in your view, would this be a vote for locking the comments and rewriting the article?
It would be a vote for re-writing it, and leaving comments open because this discussion has nothing wrong with it.
The biggest issue with any new "react killer" or "jquery killer" or "x y z killer" type of product is that is not backed by big guys. The naming of "rawJS" almost got me thinking it is some sort of new javascript framework where you write code in raw js, which it isn't as mentioned in the title as "Vanilla JavaScript is the future."
Yeah this is certainly a point. Though Svelte isn't backed by big money, it's doing alright.
Vercel backs Svelte up. Big money.
Yes, though IIRC that only happened well after Svelte gained traction and notoriety.
With all the heat this guy got for not posting he made rawjs i'll clarify mine.
I wrote Taino JS as a proof of concept just to help me understand how JS frameworks can create full functional websites.
Turns out it only takes like 5 methods and you can easily write your own.
taino.netlify.app/
Now, in my case, i'm not a JS expert though i can debug most things JS [i'm probably really damn good compared to a lot of devs but pretty terrible compared to those guys who can quote JS documentation by heart]. So, I leveraged HTML and CSS in a way that still caches them within the JS and a single main CSS file.
Either way, my code works too...and it's just to show the frameworks are massive overly bloated pieces of crap we never needed in the first place if someone like me can easily make websites with a few kbs of Vanilla JS
[edit] forgot, the whole reason i commented was to say that i think a lot of seasoned devs like me wanted to know how JS can do full website interactions and wrote our own little monsters. That doesn't mean our stuff sucks...it just means we took the time to do it and understand it, something you haven't done [yet] and maybe, just maybe, some of our solutions are far more efficient than large team built overly complex approaches to the same problem. Remember, facebook and google threw their best guys at this. You don't ask PhDs to fix bicycle, they'll recreate the bike and add fifty features you never needed to it. That's exactly what react/angular/vue became.
Well, to defend the points of my attackers, (I'll love my enemies, they'll come around eventually) the points that many of them are making is that the frameworks become increasingly necessary as apps get larger.
I guess my general thesis is that this is only true in the case when you don't employ measures to mitigate this.
I think the problem I'm having with this article is that "building large-scale apps with vanilla JavaScript" isn't an article. It's a book. There are things that need to be left out, but when people read this article and don't see their objections being addressed, they assume I'm a low-experience coder.
I remember when Rasmus Leerdorf said PHP frameworks are crap and PHP is already framework. I kind of feel that way about vanilla JS in the browser. But the popular frameworks keep people a bit more on the same page. I share your sadness over the state of react dominance in web dev. Give me OOP and design patterns in a static typed lang any day, sanity and structure, over that hot mess. Good on you for trying to sell your creation. The level of butthurt in here is like totally uncalled for.
To be fair to everyone attacking me, I did come down pretty hard on React, and my supporting argumentation could have been stronger.
Looks like a few libraries I hacked together a long time ago, before React became as popular as it is. I remember having implemented a super similar CSS solution in one library and even had another library called
hat.jsthat was very React-like but used template literal instead of JSX. Of course, everything back then was class-based (rather than hook-based), even though classes only just came out and were mostly only supported via babel (or a cool library by Andrea Giammarchi). It was fun timesWhen you implement something like that creatively, you always discover cool patterns, and that's always nice. At the same time, I think you largely overstate the drawbacks of using React and the benefits of these new patterns you discovered. It's definitely not my experience that React overcomplicates your codebase - quite the opposite - it organizes it very nicely, and in all honestly, I can definitely see that being much more of a problem if anyone uses your solution due to it using classes (opening it up to inheritance), likely hidden bugs, weird syntax, lack of proper state management, lack of clear update procedure, having to manage your own DOM manipulation, etc. The example you gave of React complexity being too much and reducing the app size by 90% with your solution, makes me believe that there was a lot of React incompetence in your team and that if the rewrite was picked up by a few devs who were good with React, you'd be able to reduce the size by 95+%
My suggestion would be to stay open-minded to the existing popular frameworks and actually gain proficiency in them rather than criticizing them while not actually being good at them. Frameworks like React, Preact and Solid are actually fantastic and there's unlikely to be something better than them, in my strong opinion. There is a lot of creative space, even within the frameworks like that
I will prefer declarative functional components over imperative class equivalents all day long. Developers need to focus writing the logic of their apps, rather than burdening themselves with the low-level details of DOM manipulating API. React, Vue, Svelte, and others are popular for a reason.
These days I prefer something along the lines of HTMX and some vanilla javascript to make things interactive/cool on the front end. I'm building, at the moment, a web app using it.
State is entirely server-side. Which in this case is a good thing, because it's a browser game. Basically, the server sends HTML and CSS, which renders at astounding speed and without a page refresh. All done through simple and easy to understand HTML markup and hx attribuites; for. me it feels seamless.
You can add HTTP requests: GET, POST, PUT, DELETE to any HTML element. For example, you click on a button and open a modal. The button click issues a GET request to the server, which returns the HTML for the modal. HTMX then renders the new HTML, thus the modal is open.
Managing a complex UI from the server has never been easier.
HTMX leaves a small footprint, but provides vast power. Suggest people check out this approach, especially if you want a fast, reliable, and secure website.
I have to say I really can't take this library all that seriously when its website and this post sound so incredibly sales-y. There's zero code or documentation on the page, literally just marketing talk.
Your page is also pretty awkward on mobile, with tiny text all around. IMO not a great showcase for something you claim is a viable replacement for major frameworks. Btw, your "check out squares" link links to the colors demo project, which I assume is a mistake.
Your "big project with a highly advanced UI" has a landing page similarly broken on mobile, with a broken link to Google Play.
And then of course this post... You write as if you've just discovered this super cool thing, but you didn't. You wrote it and you're trying to promote it. Which is ok, but then just do that, don't make it sound like something else.
Don't get me wrong, I'm all for trying new things and very much into new interesting libraries like this one genuinely could be. But given how you present it, I'm not all that interested... sorry.
Years and years ago, almost two decades now, I built an application that used the DOM and vanilla JS. I was very happy with that project, but it took me several months. Now I can do the same thing in about 20 minutes with React. I'm quite positive React adds a lot of overhead in terms of code size and execution time, but what I save in terms of coding time is unreal.
Also, I'm no fan of Angular for a lot of the reasons you have issues with React. There's Angular specific tooling, complexity, and prescribed patterns. But I've realized what both Angular and React offer is a standard around which teams can coordinate efforts. Angular is more prescriptive, but that can work in favor for large apps managed by large teams.
The DOM is a standard too, but one that was badly designed from the get-go. If you never had the misfortune to work during the "browser wars", Douglas Crockford's presentation "An Inconvenient API - The Theory of the DOM" will give you a taste. There have been a myriad of efforts to tame the DOM, from jQuery to YUI to Handlebars, and on and on. Thankfully the W3C, prompted by the WHATWG, has been guiding increasingly forward thinking advancements to web standards.
But what you're also missing by avoiding React is all the build and deploy tools that streamline your work process. With SST and OpenNext, I can have a CDN hosted site up in about 15 minutes flat. Standards empowered by powerful build tools are ecosystems that rise and fall, but that evolutionary process is where the real progress lies.
"Years and years ago, almost two decades now, I built an application that used the DOM and vanilla JS. I was very happy with that project, but it took me several months."
See that's the thing about vanilla JS. It really depends on how you're using it. You can use it poorly, which results in 20 minute projects that take months. (I'll assume that the 20 years younger version of yourself was a significantly less competent programmer than the you of today). Or you can use it well, in which case, the experience can be better than using a framework.
"But what you're also missing by avoiding React is all the build and deploy tools that streamline your work process."
Well, I can have a vanilla JavaScript app built and deployed and hosted on CloudFlare Pages or Netlify in about 60 seconds. (Maybe this is fodder for a future article)
Great article, and congratulations on seeing your project through!
I've used React for nearly 8 years. I'm an advocate; I've gone as far as creating my component library, finishing my second app with it, and planning to do many more.
That said, you made some great points, but I don't agree with some. I don't find React to be extremely complex. While it has many features, you can do a lot with a little; you don't have to use it all. To your point, some of those features/complexities came into play because of challenges presented by FB, challenges you do not see in most apps.
I have considered building a browser extension, and something lightweight like this could be very useful.
My top concerns are scaling and performance. The most important attributes of a scalable front-end system are modular and reusable code. I often achieve this by separating UI and state and dumbing down the components. It's late I may not be processing this correctly, but it looks like state management has to take place within the component. Also, in that part with HatJS, triggering functions on a parent component feels like trouble waiting to happen. It'll pass on smaller apps but would quickly become an issue on large projects with large teams.
Overall, I don't care that you wrote the library. You worked on it. You should promote it. I look forward to taking a closer look when time permits.
I love what I do, but sometimes I hate how uptight our peers can be.
Keep going!
This is literally Lit or Web Components or just plain ES6 classes. It’s not a pattern. A “micro library” is just a cope for doing no actual work.
Stop calling this a React killer. It misses the point that ES2020+ can do a lot of powerful stuff already. In fact, this pattern would be pretty great inside React or Lit! There’s two communities you just rejected for no reason; one for being ignorant of prior art, and the other for literally insulting them and saying their framework needs to die.
By the way, “Vanilla JS” means “no framework.” It certainly precludes TypeScript.
If you’ve never heard of Inversion of Control, you should be reading, not writing.
If you think people are being mean, don’t hold yourself out as an expert, and don’t call your product a “React killer.” It’s lame and disingenuous. When you raise the stakes like that, your library better be novel and worth it, or people will be understandably upset at you.
I am mostly versed with vanilla JavaScript and jQuery. My method of mapping DOM elements to "class" functions representing components in the interface works well because the interfaces do not contain complex interactions. React interfaces are more complex and I haven't had the chance to build such an interface yet. I usually use the prototype, add some functions to an object and then use it. I always pass on a $root element to such a "class" function and then I access inner components with $root.find() and pass them on to more "class" functions.
Raw.JS seems to be a function that allows developers to create DOM elements. It is not a library yet. In my opinion you are starting a new front-end framework. I'm curious to see where it can go, but I'm not yet seeing how it can beat React. It might be good to have a React example and see how Raw.JS deals better with it.
Also, the presentation website is nicely done!
Like many libraries before frameworks like React were a thing and became popular.
I wrote WizUI over 10 years ago to avoid the verbosity of the DOM API, and limit redraws.
Too many developers focus on writing new libraries instead on improving or at least looking at what exist.
Sure lightweight is cool but stop reinventing the wheel.
It's not a great metric that you rewrote an app faster in RawJS. The old projects is probably a bit over complicated by all the requirement changing under their development. It's always easier in hindsight to write a program when you already know and tested the requirements. I'm still not convinced that RawJS isn't just another framework.
The project was inherited, so we didn't really "know" it so to speak. That said, the team I'm is more competent than the previous, so I'll grant that.
If you define jQuery as a framework, then RawJS is a framework. But then lodash is also a framework. lodash is a simple tool to accelerate array manipulation. RawJS (and similar libraries) are a way to accelerate element construction. It's not an "environment" like React and requires very little buy-in (aside from buy-in from working with the actual DOM).
The examples look awfully similar to Angular, but puts all html, css and js together in one place like react. What Im really confused about is that the author goes to the point where he outright calls react as a bad solution for web and says it adds unnecessary complexity for any kind of application. But doesn’t even provide one real world example of how RawJS is better at tackling complexity compared to react/other frameworks . If you are building a library or a framework to tackle complexity, the least you would do is provide real world examples in both frameworks and show how yours is better, this is also necessary to test your own claims. Your other claim that you and your friends have used the library and have found amazing results doesn't mean a thing until you provide specific examples and show why.
In your previous comments, you are wondering why people are not being nice to you. Thats exactly what happens when you write an ignorant half arsed article that tries to be over-smart and cochy about a well established tech like react and not provide any examples to it.
But just as a library, its nice, and can add a bit of syntactic sugar to make it even more easier to nest things. In all true sense thats what JSX did, making your nested calls though functions easier.
The most hilarious and ironic part is that you call it RawJS and use Typescript by default😂.
React functional components are easy to read and can use dynamic CSS inline also. Using classes in JavaScript recreates the nightmares of classic inheritance of components and properties.
Really libraries and frameworks are no longer needed with ES7+.
Interesting, but why the disingenuously written post?
Oversight. Article updated.
React is only a tool meant to boost productivity. It started with some problems shared by all developers, which the guys behind React tried to solve : DOM is slow, need for a better way to manage state across the whole app, etc.
They did a great job. Like every other tool, one needs to read the documentation, understand the limitations of the tool, and practice using it. It takes much practice to understand what it does in the background. It's at that stage that you can develop a good, working, app.
If you were developing an app with vanilla JS, you would eventually end up realising you need : a module bundler, a transpiler, a way to render on the DOM faster, etc... basically, you would be re-inventing the wheel, you would be spending months building the tooling before being able to develop your project.
At the end of the day, the purpose is to build a product that will sell.
It doesn't matter whether you use React, or Vue or Svelte or even jQuery. What matters is to master one of these libraries to then be productive. And these libraries are all there to allow the dev to get started quickly and focus on his project.
Some points:
That said I do agree that end the end of the day its about productivity. I think the place where RawJS (and similar libraries) shine is doing stuff that isn't the typical business form filling stuff (drag-and-drop editors, graphic design tools, etc)
There are really a lot of comments here.
While dev.to seems to encourage discussions, in my experience, continuing discussions using the notification feature doesn't show the entire thread, and finding new comments within the entire comment section of a post can also be challenging.
However, looking at the increased number of stars for this post due to its impact, it seems like the fatigue might be worth it.
I personally don't find the syntax of libraries like rawjs or vanjs to be ergonomic compared to Svelte's syntax.
However, seeing similar libraries frequently on dev.to makes me think that people might surprisingly dislike HTML syntax.
What are the specific advantages of rawjs compared to Svelte?
Storing the state in the DOM?🥵 What if you're displaying the data in multiple places?
HatJS solves this (as do probably some other libraries that have pub-sub functionality). I didn't include it in the article because from my experience it's an edge-case (not being in multiple places, but being in multiple places at the same time)
I am sure Paul wants to make tools that help people do things differently, which is good for progress. But saying React killer in your bio right away isn't the best idea. React is really liked because it's good and many people use it. It became popular because a lot of people liked it for a long time. We should appreciate the community behind React. React has won people's hearts for good reasons, RawJS might be good too, let people explore and say that. Thanks for your efforts Paul, keep creating.
I'm dissapointed by the idea behind RawJS, It's almost like it screams the contradiction "Be free and write raw code for yourself (The Way That I Told You Too)". It's very backhanded and missing the point that "raw" code is what happens when you let go of needing a framework, not jumping into another one.
Raw JavaScript is the beauty that emerges when Enginners start solving the problems in front of them (without frameworks, even this one).
Everyone should stop what they are doing right now and go to heropaul.com. It's that good
We can talk all we want, but the man looks good in that white shirt.
Thank you good sir 🤣🤣
Deny all you want, but the title is pure clickbait written to appear as a third party. Your bio isn’t even anywhere near the title or header. The copy indicating that you’re the author isn’t reflected on the media sites that show the title of the article. The title is clearly meant to mislead and hide the fact that you’re the author.
Whilst I agree with many of the points, I simply find it hard to trust this framework now.
An "oversight" ha
It was in my bio the whole time. I'm sorry you skipped over this.
Paul, homie, this a time to show your emotional intelligence. People are understandably upset about your oversight, playing this like they're being unreasonable is probably not the right play, because they're reacting to something that actually happened, mistake or not. I haven't even read your article yet, this drama is overshadowing your launch. Embrace, apologize and move on.
Now on to the article.
Well, it was in my bio the whole time. People skipped over it and assumed I'm some snake-oil salesman (?). I did already admit that it was an oversight / learning opportunity.
I dislike everything about this article and the associated libraries.
I appreciate the positivity! 👍
Greatt article ! 👌🏼
Just , there is a repeating typo.
EventListenerfuction's first argument starts with " but ends with 'Why three separate libraries RawJs, HatJs and Rawter?
Because they all do one thing well. RawJS for example is also powering a static site generator (StrawJS).
The solution is probably to have better scaffolding tools that put all this stuff together more quickly.
Isn't private in vanilla js declared using # and not 'private' keyword?
Does "vanilla JavaScript" not also imply "vanilla TypeScript"?
I agree with you. I don't like react. But adding something like rawjs is adding another black box to my project. And I don't want it unless is completely unnecessary.
I agree with you re: black boxes. I hate them. But... I don't think all black-boxes are created equal. For example, I don't know have first knowledge of the inner architecture of jQuery, but I wouldn't call jQuery a black box. I think RawJS falls into this category. It's literally just ergonomics for document.createElement() and almost nothing else.
Check me