91–100 of 135 posts
https://medium.com/@arannadelwar361/embracing-the-power-of-r... https://dev.to/paulgordon/after-using-rawjs-im-never-touchin... Both links helped to explain, the landing page is indeed not very good.
lol geez the React devs in the comments of that dev.to post are out for blood
I wish I could upvote your comment a thousand times, after spending literally the whole day so far trying to pour water on a burning building.
From the example repo: > You have to be disciplined to only use dependencies that are published on jsdelivr (npm install programmers need to clean up their act) Yeah, no thanks, I'm sticking with my "unclean" ways.
You have to admit at least admit that minimizing dependencies is an admirable goal (despite my tougue-in-cheek comments in the readmes I write)
I'm gonna be honest, you need someone to proofread your website. I spotted two typos on a quick scroll-through, both of which could probably be caught by copy-pasting the thing into Word.
Honestly this whole thing blew up so fast I wasn't expecting any of this. The home page for the website isn't even done yet.
Earlier quoted context omitted.
The sample repo is at least well-commented. I've taken the liberty of pasting some of the sample code here, sans comments, so we can see what the code style is like. My editorial take: no thanks. This looks less declarative than jQuery. If this is the alternative, then yeah, you still probably need React (or Vue/Svelte/Astro/whatever) namespace App { export class SegmentedButtonComponent { readonly head constructor(.…
...yuck. The hilarious part to me is that every single thing this does could be done in one line of an angular template with massively less typing and opportunity for error. just a: Like, I know you want to create an element and blah blah...but if it takes your dev 4x longer to write it, why are you doing it? Ultimately, in the real world, all of this is devs trying to make bragging rights for reasons with no real co…
I have to say this is a bit disingenuous. You pulled the segmented button component which in a real-world environment would just be a part of a library. You should show the part where it gets used. From my experience, how this ends up playing out in a real-world environment is that these things end up getting boxed into higher-level UI libraries that turn all this stuff into quick function calls.
The vast majority of devs aren't (and shouldn't be) writing their own custom components.
Earlier quoted context omitted.
my reading on the "limitations you need to accept with this project structure" is that those limitations are about this particular project structure, not on rawjs itself; i.e. my understanding was that you can also write a project using rawjs using normal ES modules and plain JS (as mentioned briefly in the main rawjs github repo readme). that said, I do agree that pointing to a highly opinionated example project is…
My point is that, this being written by the authors of Rawjs, who unironically proselytize that "npm install programmers need to clean up their act" while providing a project which would require you to `npm install` dependencies is telling.
I guess they forked Vapor.js? :) https://github.com/madrobby/vapor.js
I didn't fork anything.
And your link just pr0n'd me in a coffee shop.
Thank you.
> RawJS is a better way to call document.createElement(). React is a way to reduce calls of document.createElement using virtual DOM, ie using React.createElement. It’s JSX which is supposed to be a better way to call document/React.createElement. So what exactly does this compete with?
The main thing RawJS brings is ergonomics when creating element hierarchies of plain HTMLElement instances. I don't see JSX as something that does this very well. A lot of people don't like JSX, because its not JavaScript. There are other libraries that are better document.createElement() that work somewhat similar. RawJS isn't new in this regard, I just believe that it's better executed than the others.
Earlier quoted context omitted.
This is the third or fourth time I see today in HN of someone treating someone's personal project or opinion as "the direction the community is moving". If every new toy framework is treated like this, it's no wonder people feel overwhelmed by frontend development.
RawJS library author here. Moving away from modules is definitely not what I've observed in the community, I see no evidence that this is "the direction the community is moving". That said, I admittedly have a visceral hatred for ES modules. I personally believe them to be the worst thing that has ever happened to the language. Encapsulation is of course a great thing but in my opinion there are much better ways to d…
Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily cut myself off from all the libraries that use other module systems. In this happy little bubble, over time, ES module support has gotten better and I've selected tools / found ways to use tools that work with modules and I rather like it.
Perhaps because I'm less invested in the tools, I evaluate the situation of "tool X doesn't support ES modules" more like "tool X isn't great" and less like "ES modules are bad".
Perhaps it all stems from being a person who genuinely likes JavaScript, has a high affinity for standards, and a relatively low opinion (yes, I'm a snob) of the Node ecosystem?
How does this compare to SolidJS which uses JSX and performs insanely close to vanilla JS already? If I really want to shrink my front-end I might as well, just go for Solid or Preact.
I think it's probably more fair to say that SolidJS is "insanely close" to React rather than RawJS.