-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
No build frontend dev is a thing, although obscure.
Preact has a no build path in their documentation: https://preactjs.com/guide/v10/getting-started/#no-build-too...
And here’s my no build react setup: https://github.com/jsebrech/create-react-app-zero
I had the same issues when I started with https://emailengine.app - just like Ghost, it’s an app written in Nodejs. I tried multiple distribution options at first and finally went with complete self containment. All modules are pre-installed during the publishing step and thus the user never needs to run npm. Or if you download the “compiled” single binary version you don’t even need node as it’s bundled with the binary (I use the pkg module to bundle these executables). So upgrading is just downloading and replacing the old version files with new ones.
The dowside - no sane way to use compiled dependencies, everything has to be vanilla javascript.
I like posts like this, because software with these properties does deserve to be roasted. It seems like no one can figure out or remember anymore what's wrong with it, though. It's a valid question.
But a couple clarifications.
I don't develop or distribute software that depends on Node, but I imagine deciding which versions of Node to support, or conversely require, for software like Ghost, is a bit like deciding which Java VM versions to support, or which browsers to support. That is, there is a lot of compatibility between Node versions, but do you just develop and test on the latest one, or do you make an effort to support more/older versions? In this case, Ghost seems to be tested on v12, v14, and v16. The author seems to mistakenly think that only the "Active LTS" version of Node gets security fixes, but that's not the case, v14 and v16 are in "Maintenance LTS" and receive security fixes. That said, their "ends of life" are in April and September of this year, for whatever that's worth. At the end of the day, I think it is considered easy to update and/or run multiple versions of Node. I'm don't know why an app written for Node 16 wouldn't work with a newer Node 18, though, that kind of stuff annoys me sometimes.
For the MariaDB support, I googled and found this note from the Ghost devs: "Note: MariaDB is not an officially supported database for Ghost. It just happened to work given the similarities with MySQL, but we optimize and test for MySQL 5 and 8. As of Ghost 5.0 we are clarifying that official support is purely for MySQL8 in production so that we can double down on DB optimizations." Maybe that's what we're talking about? https://github.com/TryGhost/Ghost/issues/14446
Now, the deeper trend that I think is misguided is the rate of iteration and breaking changes, and apps and libraries having too many dependencies. The problems propagate through the dependency graph. Someone releases a library, and then adds a bunch of features, and then rewrites it, adds features, rewrites it again. That's fine for some hobby project that no one is using. I think anything I say won't be appreciated by someone who hasn't experienced programming and computing any other way, e.g. writing Java applications in the 1990s and 2000s. Or even just using desktop applications in the 90s. Software used to sort of "mature" and then continue to be used and supported, while staying pretty much the same, for years. It wasn't constantly rearranged to use new versions of things that are constantly rearranged to use new versions of things that are constantly rearranged etc. etc. etc.
> If browser vendors bundled tsc or its equivalent then we'd both be stoked.
Not exactly this, but there was a proposal that would allow for typescript type hints to be considered as normal JS syntax: (in the same way python PEP 484 – Type Hints are considered optional type hints)
https://github.com/tc39/proposal-type-annotations
Deno on the server side is pretty cool and uses https://swc.rs/ (Speedy Web Compiler) - doesn't take forever to start, but kinda implements typescript as if it was just a type annotations without the more in-depth actual type checking, so it is possible.
> If browser vendors bundled tsc or its equivalent then we'd both be stoked.
Not exactly this, but there was a proposal that would allow for typescript type hints to be considered as normal JS syntax: (in the same way python PEP 484 – Type Hints are considered optional type hints)
https://github.com/tc39/proposal-type-annotations
Deno on the server side is pretty cool and uses https://swc.rs/ (Speedy Web Compiler) - doesn't take forever to start, but kinda implements typescript as if it was just a type annotations without the more in-depth actual type checking, so it is possible.