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.
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.