It's extremely worrying on how they had to use a private "foundation" rather than using existing, more democratic, organizations like OpenJS foundation.
Don't expect user input, don't expect changes that go against their wants over the community's needs, and don't expect things to get better.
Really feels like react has held back frontend development. The idea that everything on the web should be written in react is baffling but I'm sure people thought similar thoughts when jquery or angular were popular.
This could be because of developer fatigue and the trend of forcing backend devs to do fullstack.
Its very hard to keep up with the frequent changes to programming models, new frameworks, CSS libraries (why the heck are they soo many?!) when you also have to design O(Log n) backends, IaC, Observability, LLMOps, etc.
I have come to a compromise and have started advocating for React/Redux/TS/NextJS as the default CRUD application stack so that I can focus on solving real CS problems in the backend that I’m passionate about.
But react is where developer fatigue is most endemic. Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time. You can easily tell when a react project was started based solely on it's dependencies. This is bad because it typically means no two react projects will use the same dependencies.
These dependencies are the root of the issue.
FWIW, I've only ever professionally work with react on the frontend. For nearly 10 years too. My first job I was doing react.createElement() before classes were shortly introduced afterwards.
It's time that we move on to something better, and the react foundation being controlled by private entities while not being an actual democratic foundation is a good omen of what to expect.
> Since it only does one thing, that typically means you have to import a dozen other libraries that are mostly "flavors of the month" captured in time.
By weird happenstance I got a job writing in a half-dead, compiles-to-JS language 5 years ago. There's one way to handle state in it. My view on the libraries you need to handle everything-but-view in React has been "I'll come back to these when the dust settles" and it just never settles.
Forget the underlying language, the real shift was this idea that every website should be a single page application, which we are now moving away from again but seemingly everyone has forgotten how to do it, so it's being done "the React way".
None of these have usage numbers that rival react, at least not in the US. I wish it were so because many react libraries can easily support other view libraries with minor modifications to decouple it from react.
I'm fine with it. I love dogs, and I find suggestions that LLMs may achieve sentience or become conscious either laughable or abhorrent, depending on how serious the person is who's making them.
It's still OK to use dogs as an analogy. In this case the analogy is to unreliable tools, and dogs are unreliable tools.
I don't find "stochastic parrot" offensive as an analogy, even though it's got parrots in it.
My only context in using Lua is my neovim configuration, does any know of any good books or tutorials that make something more advance using only lua? Anything of note to consider/read/watch?
Shameless plug time: I have written a public domain book which looks at using Lua (Lua 5.1 but the code works in newer versions as well as Lua 5.1/Luau/LuaJIT) as a text parsing engine. The book assumes familiarity with other common *NIX scripting languages (such as AWK, Perl, or Python) and goes over in detail the pain points for people coming from a *NIX scripting background:
Thanks for recommendation and writing the book! I'm reading the introduction, it doesn't answer why you chose to fork lua and create lunacy. What were you trying to solve with lunacy that lua couldn't do?
The TOC looks great, I will read this soon. Need to finish "Debugging CSS" first (another good book IMO).
The main reason I made Lunacy was to have a standard compile of Lua 5.1, since it’s possible to make a Lua 5.1 compile with, say 32-bit floats or which only supports integers but not floats.
Lunacy also has a few built in libraries which are not included with Lua 5.1, such as binary bitwise operations (and/or/xor). It also fixes some security issues with Lua 5.1 (better random number generator, hash compression algorithm which is protected from hash flooding attacks).
In addition, I have made a tiny Windows32 binary of Lunacy.
Don’t worry about the Lunacy changes; all of the examples in the book work with bog standard Lua 5.1 with a bit32 library (bit32 is common enough most OSes with a Lua 5.1 package also have a bit32 package for Lua 5.1).
Don't have tutorials or books, but I've had a ton of fun using Lua with LOVE2D [0] for gamedev, and also Redbean [1] for building super small portable web applications. Earlier this year, I built a mini CMS [2] inspired by rwtxt with Redbean.
Haven't heard of love2d but have heard of pico-8. I've avoided most game dev tutorials because they seem overly focused on beginners, which is fine, but want to find more advance materials that assume the reader knows some basics.
Maybe I should reconsider and dive more into game dev.
> It's aimed at programmers who have some experience but are just starting out with game development, or game developers who already have some experience with other languages or frameworks but want to figure out Lua or LÖVE better.
Also on the topic of game engines with lua scripting, the wonderful Defold always deserves a mention https://defold.com/
Definitely include Roberto's Programming in Lua book in your list. Specially if you'd like to script Lua together with C. The book has a good primer on the Lua-C api in its latter half.
I always wrote Lua off, scoffing at the 1-based indexing, until I was "forced" to learn it thanks to Neovim. What a delightful little language it is. I do wish I could do certain things less verbosely (lambdas would be nice) -- but then again, I defeat myself by suggesting it, because not having all the features makes Lua so approachable.
I used Lua professionally. I prefer the 1 indexing... it just feels more natural. For some reason the C apologists here will scream how 0 based is the only way to go. (which is not, it is just a historical artifact). Languages like ADA allowed you to use either 0 or 1, (or any arbitrary) starting index.
Same here, in fact something I wish the neovim team would do is create a book where popular plugin authors create tutorials that recreate basic functionality of their plugins.
Seems like a no brainer that would help bring in more revenue too, it'd also be an "evergreen" book as new others can contribute over time.
I can't be the only one that would immediately buy a copy. :D
I'm actually trying to work on a video-series to do just this. I've made my own rudimentary plugins reproducing several popular ones, and would like to walk through how I made: a) file-tree b) picker/fzf replacment c) hop/leap replacement d) surround plugin e) code-formatter f) hydra (sub-modes) g) many "UI" (interactive) buffers, etc.
None of these are published because the popular ones are better and provide more functionality, but I want to share what I believe is more valuable: what I learned while writing them.
(I personally don’t use patches like this because “Lua 5.1” is something pretty standardized with a bunch of different implementations; e.g. I wrote my Lua book with a C# developer who was using the moonsharp Lua implementation)
There’s no proof that this exchange ever happened. Happy to eat crow if proven wrong. I’ve disagreed and argued with Ed on his subreddit, he never banned me or acted hostile.
I'm using wpForo since it integrates well with my CMS. The first users showed up in the first week, mostly because I directed YouTube questions that required posting error logs and the like to the forums. It has been a good tool for helping people out.
reply