452 karma · joined March 4, 2022
Then it's childish for you to tell a flat earther they're mistaken. The objective, historical facts are on the side of Catholicism, whether you want to admit it to yourself or not.
People assigned it capability beyond its ability. That's the entire problem with AI. It is not intelligence. It merely mimicks it. What atheists call human intelligence is actually an ability we have because we're God's images. Making something in our own image and calling it a god is deeply biblical and culminates in Revelation 13:15.
Every atheist on here, but more particularly, the elitist tech communities that think science is all there is to reality, when life experience abundantly proves otherwise from every direction.
Stupid analogy after stupid analogy. The printing press merely let us mass-transmit ideas on paper. The whole point of AI is to be able to imitate the human mind, through a neutral network created via software and data training.
I have no problem sitting by while fools use AI to create inherently doomed works of art and prose.
But first we need a valid syntactic sugar transformation, which I propose here.
Then we need to implement it in things like babel[0] bun[1] and deno[2].
Then, frameworks would adopt it as an optional alternative implementation.
Eventually, it could gain widespread support and become standardized.
[0] https://github.com/sdegutis/vanillajsx.com/blob/main/site/un...
It just runs your code in a node.js process, and translates your JSX expressions into jsx() calls. On the node.js side[2], jsx() returns a string from its tag/attrs/children. On the browser side[3], jsx() returns DOM elements.
Combined with a little bit of architecture, it becomes something extremely well suited to creating static sites. I guess SSG is an outdated term now, maybe it's a framework? Or a platform?
In any case, it seems to do something similar to Astro, but in a significantly simpler way. The only "bundle" it needs in the browser is /@imlib/jsx-browser.js [4] which in itself is just jsx-dom.ts (its impl is overridable by the "framework" user). And on the node.js side, it's implemented as a very small "vm" of sorts [5].
I'm not against Astro, I just get all the same benefit people here are saying Astro has, but with orders of magnitude more simplicity imo.
I've used imlib to make a relatively large website [6], in fact imlib was developed as this website and extracted from it over the past year. I have absolutely no difficulty breaking down my site into various reusable and encapsulated JSX components, both on the ssg-side and the browser-side. Development time is lightning fast. IDE support is essentially automatic. The site loads instantaneously in the static parts, and as quickly as reasonable in the dynamic parts.
[1] https://github.com/sdegutis/imlib
[2] https://github.com/sdegutis/imlib/blob/main/src/jsx-strings....
[3] https://github.com/sdegutis/imlib/blob/main/src/jsx-dom.ts
[4] https://vanillajsx.com/@imlib/jsx-browser.js
[5] https://github.com/sdegutis/imlib/blob/main/src/runtime.ts
Technically this is the only code bundled with vanilla jsx:
Another user below said
> We've recently moved one service from next to Astro and it was just removing a ton of boilerplate and 'dance around' code.
And I get why it happens. When you first try out a new framework, you allow yourself to learn and add its inherent complexity, knowingly and intentionally. You say to yourself, "it's part of the dream, it's going to work out; there's a vision, just trust the process." This is true with literally all frameworks.
But they never deliver. The complexity is never worth it, and in the end, the intentionally added complexity is always intentionally and gladly removed when it becomes clear that it was unnecessary complexity. This is what I am glad to have learned so thoroughly that I no longer try to learn new frameworks when I initially see its complexity, imagine adopting it in view of my experience, and recognize that its almost always not worth it.
Look at the code on vanillajsx.com. Besides JSX and types, it's plain JavaScript and DOM manipulation. Translating it to document.createElement would add almost no lines of code. There's no unnecessary complexity. That's the whole point of the site. The simplicity of discovering and removing unnecessary complexity is wonderful and refreshing, and I think a lot of people agree.
Specifically, I'm hoping to show that vanilla architectures can be not only performant, but easy to maintain with well designed code that uses stable and known patterns. Using JSX just so happens to clean up the code nicely and make the relationship between React and vanilla very visible, but that's really all it did here.
Although to be fair, the hack required to get JSX-as-DOM to work is really unfortunately and I'm not very happy with it, and I would prefer JSX to just render as an object tree that anyone can render however they want. But when I tried that for a few months or a year, it was not nearly as performant as rendering them as strings as soon as they're evaluated, which can then be cached via standard module caching. At least, that's how I got immaculatalibrary to entirely render all HTML files in ~700ms initially and ~70ms on most file changes.
I'll try to do some experimentation next week to see if I can get more performance back out of having <foo bar={qux}>child</foo> to render as {foo:{bar:qux, children:[child]}} again though, because that would absolutely be the ideal, and would unfork JSX in the same way Typed Annotations proposes to unfork JavaScript types.
I get the "no more imperative updates" dream. I've used these frameworks for probably a decade. I've mastered them.
Me personally, I prefer imperatively updating my DOM. I get completely fine-grained control over what's happening. I can architect it to be an extremely efficient machine. I can make it extremely easy to add/change/remove/fix features in my apps without forcing myself to think according to anyone else's opinionated methodology.
Honestly, the real interesting part about my framework is literally everything else. Returning strings from JSX on the ssg-side; being able to import raw source directories and manipulate string|Buffer at ssg-time; the extremely efficient and lightning fast module system I wrote on top of chokidar and swc; probably more I'm forgetting, but basically the JSX-as-DOM is only the most visually interesting part. But really just a party trick.
[edit] Case in point: the source code to vanillajsx.com is extremely concise and clear and short, I literally wrote the whole thing today with zero deps (besides imlib), and the JSX-as-DOM demos are the least innovative part of it: https://github.com/sdegutis/vanillajsx.com/tree/main/site
* https://www.immaculatalibrary.com/books.html (src = https://github.com/sdegutis/immaculatalibrary.com/blob/main/...)
* https://www.immaculatalibrary.com/prayers/ (src = https://github.com/sdegutis/immaculatalibrary.com/blob/main/...)
[edit] Oh also, this solution works really well for SEO. That's another problem I didn't find solved well in other JSX frameworks.
Right now I only feel qualified to say I am excellent at React, JavaScript, TypeScript, jQuery, Node.js, and similar.
What I need is help on figuring out how to find a job that makes me $50/hour and doesn't kill me.
And for everyone here, I am not suicidal. I am just really, really tired of life.
Which is why my goal is to get a job, and not start a gofundme.
Location: Chicagoland
Remote: Yes
Willing to relocate: No
Technologies: TypeScript / JavaScript / React / Node / etc
Résumé/CV: https://sdegutis.github.io/resume.html
Email: sbdegutis@gmail.com Location: Chicagoland
Remote: Yes
Willing to relocate: No
Technologies: TypeScript / JavaScript / React / Node / etc
Résumé/CV: https://sdegutis.github.io/resume.html
Email: sbdegutis@gmail.com