> All the tools require me to do so much bullshit to get them to even compile. I shouldn't need to compile JavaScript to JavaScript in order to deploy stuff to a webpage.
I've never understood why this is deemed such a big ask by so many people. You can either compile JS-to-JS or have your JS break when it encounters an old browser (which is exceedingly rare, these days, so you don't really need to compile JS-to-JS. Most of the "bullshit" [aka tooling] these days bundles and optimizes your JS).
Many languages have compilers that you need to run. Before running a Java program, you need to compile it. And compiling things with `javac` is hardly simple. You need to populate your classpath, configure all kinds of stuff. It's not trivial. So why is it such a big deal when you need to do the same thing when making a webapp?
To make meaningful, portable applications in JS, you need to use a compiler. That's both due to the varying runtimes your code will encounter, and due to the fact that your application consists of many files that benefit from being compiled together by tooling versus by you, by hand. Configuring such a compiler (webpack, parcel, rollup, etc) can be of varying levels of complexity. Next.js makes starting a webapp trivial. It's what create-react-app should be.
Yeah, if you want to just make an HTML, that's fine, you can just roll some JS and it'll probably work in most browsers. But if you're making an application, then it makes sense to start using some tooling. When has this not been the case in web development? Even before client-side apps really took off, getting your server-driven HTML-emitting application going was hardly simple.
> I've never understood why this is deemed such a big ask by so many people.
It's the “Script” bit of “JavaScript”. Once your scripting language needs compiling, it's jumped the shark. You need to go back to the drawing board and invent something else. “I don't want to compile JavaScript” is the face of it, yes, but at its core, this sentiment rails against the entire bloated, over-developed, under-engineered state of contemporary JavaScript.
Ironically this is the kind of thing that ES6 modules actually solves. It's even better if your tool is internal-facing only so that you don't have to bother with the release time older browser compatibility thing.
ES6 modules are just brilliant, it's like a breath of fresh air in JavaScript development. Your browser sees exactly the same thing as you write, which is such a great simplification. And yeah, you can still bundle/minify for production...
Very nice. I’ve been coding for decades and love how much you can learn in just a few seconds from collaborating with someone or in this just looking at their code:
Author of the post here: If you are not sure this is serious or not I have succeeded at creating enough surrealism to make you not sure.
RE: React, to quote my own post:
> All the tools require me to do so much bullshit to get them to even compile. I shouldn't need to compile JavaScript to JavaScript in order to deploy stuff to a webpage. I don't want to give Facebook a grant to any patents I end up creating.
Yeah I read the patents thing and decided this couldn't be serious because you don't need to grant facebook patents to use React. Saying things like that doesn't give the post credibility, just snark.
If I'm wrong, then please show the credible references with links.
>>All the tools require me to do so much bullshit to get them to even compile.
This is flat out wrong too unless you're referring to the situation pre 2016 before Create React App.
It's false information.
There's better and more valid criticisms of React such as for example why does it hijack CSS when it really absolutely does not need to and this causes all sorts of problems.
Things that are one step for you may be way more than one step for others. I want to avoid complication whenever possible. When I need to write JavaScript, I just want to write JavaScript instead of doing so much bullshit to get it to fit into Nix or `go build` or whatever.
`create-react-app` is great for other people, but other people have different constraints and you cannot expect your experiences to be universally understood and accepted as fact.
I don't understand this criticism. Which other language lets you get away without compilation or build of some kind? Every language I have used has some form of build or compilation step before running the program. Unless you are building absolutely trivial programs like a "Hello World" you have to do some amount of build/compilation/orchestration (whatever you may want to call it).
The main problem is that `go build` has no escape hatches for running arbitrary code at compile time, so I want to remove ways for me to get the code in emacs out of sync with the code that runs in the binary. In this case it means ripping out literally everything involved with JavaScript build tooling. This also helps keep the semantic space for the service down a lot.
The onus is not on anyone to explain why React shouldn't be used. The ordinary state of the world is not React. It's not a naturally occurring substance. The onus is on you to show why the React ritual and all the boondoggle that comes along with it is justified.
To put it another way: "I don't understand your criticism. Christine has a workflow. (As it happens, it doesn't involve running a build step.) What's the problem?"
> You know what's easier than doing that? Not doing it.
Great! And you can do just that. Explained below with an actual working example.
> The onus is not on anyone to explain why React shouldn't be used. The ordinary state of the world is not React. It's not a naturally occurring substance. The onus is on you to show why the React ritual and all the boondoggle that comes along with it is justified.
The onus is on nobody because it is Open Source Software. If you want to use it, use it. If not, forget it and do your own thing. People use React because they like the bells and whistles that come along with it. If you really want to learn React, just pursue the documentation. Asking random people on Hacker News to prove to you why React is better is not going to get you anywhere. No one has an onus here to explain anything beyond what they can explain in the limited time they have.
> To put it another way: "I don't understand your criticism. Christine has a workflow. (As it happens, it doesn't involve running a build step.) What's the problem?"
Common myth for those who have never used React. The belief that you have to use a bundler.
The idea is not whether you can or cannot use a bundler. It is about why people use a bundler in the first place. That is what you need to grok. That cannot be a point of discussion. It is something that has to be learnt first. Only when you learn how to use the tools can you say conclusively whether the tools are good/bad. What you are doing right now is presenting a shallow argument about why bundlers are bad based on your own interpretation of it not being an "ordinary state of the World". Tools are not meant to represent "ordinary state of the World". They are tools precisely because they don't fit the ordinary state. They are there to enhance the experience.
And to use these tools is a personal preference at the end of the day (or your company/team decides on your behalf). Whatever I or anyone else says here will remain as an opinion until you actually try it out yourself. And if you choose not to, that is also cool. You can still use React without any bundler as demonstrated above. Is the experience as great as using a bundler? Nope. Not for me at least. But hey it is after all my opinion. You might have a different experience altogether. These things cannot be point of discussion as it is subjective. What are your pros can be my cons and vice versa.
> When I need to write JavaScript, I just want to write JavaScript
The beauty of compilers/transpilers is that you can write in the latest JavaScript and not have to worry about browser compatibility, it will automatically transpile down to whatever target you want.
This library can be dropped into the headers of a html file to be used, rather than a compile step via Create React App. Create React App is likely one of the issues.
Eh, not really. I can straight-up embed the source of this and run with it if I want something that's html++ rather than "a new JS project". I know the API, because the source is simple. It's a small tool, for small jobs.
There is nothing wrong with choosing the simpler option.
It's not the same thing. GP says that the entire source code of xena can be directly copy-pasted in your business javascript code, or even in your html; no need for imports, no need for CDNs, a process under control from beginning to end.
What you're proposing is essentially saying "look, it's easy to fly, here's how you do it in python":
import antigravity
def main():
antigravity.fly()
if __name__ == '__main__':
main()
Nope. Have you actually looked at Xena's source code? She actually imports her own library:
`import { g, h, x } from "/static/js/xeact.min.js";`
Please see her source as I have used the same source, sans her library, to replicate it with React.
Instead of importing from "/static/js/xeact.min.js", I am importing React. There is literally no other difference.
> can be directly copy-pasted in your business javascript code
Why can't you do the same with React? You literally can copy-paste entire React code in your HTML. Nothing stops you from doing that. Doesn't matter if you import it as a file or inline it in your HTML. It is plain old Javascript at the end of the day.
> I don't want to give Facebook a grant to any patents I end up creating.
No longer true.
> All the tools require me to do so much bullshit to get them to even compile
Tooling has changed quite a bit. Especially with tools like ViteJS. You don't need to configure practically anything and get a project off the ground with develop/build times in milliseconds. I am happy that it is moving in the right direction. This churn was required so the industry could figure out what the pain points really are.
If this is the case, I admit I fucked up and will go correct the post with an addendum.
> Tooling has changed quite a bit.
I just wanna pull in a JS file from `go build` via `go:embed` and have it work lol. I'm not doing rocket science here, I just want thing to go. If it is not less effort than putting static files into a binary then I'm sorry but you've lost me.
> I just wanna pull in a JS file from `go build` via `go:embed` and have it work lol. I'm not doing rocket science here, I just want thing to go. If it is not less effort than putting static files into a binary then I'm sorry but you've lost me.
Why would I want to put JS/static files inside a binary? Sounds like too much effort to do something as simple as hosting the files directly.
There is literally no need to put things in a binary if all you have to do is host a static website. Some services (like Netlify Drop [1]) just let you drop your entire folder with your static files and you get a URL in the end which you can share with anyone you like. Why would I go through the hassle of creating a binary (which is way more complicated) than just dropping a folder into a service like Netlify Drop [1]?
I am just giving an example of right service/tooling trumping complicated binary builds.
You have to define what do you mean by "complex". For starters, you don't need go build or scp at all.
> managing an integration with a 3rd party using a proprietary API
Nothing to "manage" really. You just drag and drop your static files. There are no API calls, no handling exceptions or debugging build errors. Everything is automated for you.
If the 3rd party goes down for whatever reason, you can always host it on your own or on any other 3rd party competing services (which there are now plenty of that follow similar model).
Either ways, web hosting inherently is hosting on a 3rd party. It is literally impossible to host everything on your own without any sort of dependency on something: even if you buy your own physical server rack, you still are dependent on electricity provided by your Government, your internet service provider giving you uninterrupted connectivity, DNS for resolving your domain, your domain registrar etc. There is always going to be some 3rd party dependency. Whether you like it or not. If this makes you uncomfortable, just confine to developing standalone apps. You are trying to define complexity in an inherently dynamic environment that web apps run in.
To be blunt, it looks like a rehash of a tired trope. The "let's vanilla instead" snark has been a thing[0] since forever.
There's really nothing new or interesting here. `g` is prototype.js' `$`, `h` is basically a hyperscript flavor of the much older domo[1], `u` is `fetch`, `x` is `.textContent = ''`, `r` is on dom content loaded. That's about it, I think? A real curmudgeon writes those from scratch cus fuck npm /s
All the arguments against React are kinda just a display of lack of familiarity w/ the frontend ecosystem. The patent thing is so outdated it's borderline "ok boomer" cringe territory. There are plenty of projects like hyperapp and htmx that are minimalist, free of compiler BS and don't look like a high school kid's hot take on tiktok. And the thing about writing utils from scratch as a vanilla lover is actually semi serious (I've done it myself, as someone who's even developed a React-based framework at work...)
Sorry to OP if this sounds negative, but this is clearly a pretty low effort jab at the "frontend is complex" meme, and "revolutionary" is simply not how I'd describe this, even if I was being very generous.
I like it. I doubt I'd go back to a framework where the user's code is responsible for managing the DOM though. I feel like with this you either end up with a bit of "clear and repopulate" boilerplate for each component, or you build half of React yourself (state and automatic rerendering). It feels more like half of a solution to a single problem rather than complete solutions to a smaller number of problems (relative to React).
I'd probably compare this to something like Preact, which is relatively lean. The React API has always been very simple already. It's just all the other stuff people use with it that's the problem.
Author of the post here, yeah for the admin tooling that I derived this from I actually do use "components" (functions that turn javascript objects from an API into HTML elements), but the real reason I discovered this was because I wanted to do it in a way that my Haskell and Rust-ruined brain could grok. I have a hard time with React's reverse PHP stuff but have no problem translating what I can conceptualize the DOM as in my mind into Javascript syntax using this (admittedly clunky) set of wrappers. Consider code like this:
This kind of stuff is way easier for me to deal with than the equivalent in JSX. I don't know why, but It Works For Me :tm:. It also has the advantage of not requiring a separate build step so you can just slap it into a Go binary with a go:embed directive and you're off to the races.
Plus as far as I understand it's fairly idiomatic for people to reinvent their own JavaScript frameworks for when they need something between JQuery and React. Xeact (zi-act) is designed to fill that gap. Serve with laundry sauce.
You might be interested to know that in the alternate universe of Phabricator — the magnum opus of a PHP codebase that is the fourth cousin twice removed of Facebook’s internal PHP stack — there was a function not unlike the one you describe:
It’s verbose but I learned a lot from it. For example, returning a more specific type than String can eliminate a large class of security / escaping bugs.
I've never understood why this is deemed such a big ask by so many people. You can either compile JS-to-JS or have your JS break when it encounters an old browser (which is exceedingly rare, these days, so you don't really need to compile JS-to-JS. Most of the "bullshit" [aka tooling] these days bundles and optimizes your JS).
Many languages have compilers that you need to run. Before running a Java program, you need to compile it. And compiling things with `javac` is hardly simple. You need to populate your classpath, configure all kinds of stuff. It's not trivial. So why is it such a big deal when you need to do the same thing when making a webapp?
To make meaningful, portable applications in JS, you need to use a compiler. That's both due to the varying runtimes your code will encounter, and due to the fact that your application consists of many files that benefit from being compiled together by tooling versus by you, by hand. Configuring such a compiler (webpack, parcel, rollup, etc) can be of varying levels of complexity. Next.js makes starting a webapp trivial. It's what create-react-app should be.
Yeah, if you want to just make an HTML, that's fine, you can just roll some JS and it'll probably work in most browsers. But if you're making an application, then it makes sense to start using some tooling. When has this not been the case in web development? Even before client-side apps really took off, getting your server-driven HTML-emitting application going was hardly simple.