TinyDevCRM Update #2: Front-end Shenanigans
This is a summary of TinyDevCRM development for the week of February 15th, 2020 to February 22th, 2020.
Goals for last week
- [❓] Work through React.js tutorial
- [❓] Work through TypeScript tutorial
- [❓] Understand how pieces of
create-react-app
come together - [❓] Build out working, full-stack, email-based, token-based
authentication workflow with a blank dashboard for
tinydevcrm-dashboard
- [❓] “Sign Up” page
- [❓] “Log In” page
- [❓] “Forgot Password” page
- [❓] “Confirm Email” page
- [❓] Blank dashboard
What I got done this week
- [✔] Work through JavaScript refresher
- [✔] Work through TypeScript tutorial
- [✔] Work through React.js project-based tutorial
- [❌] Work through React.js step-by-step documentation
- [✔] Understand how pieces of
create-react-app
come together - [❌] Build out working, full-stack, email-based, token-based authentication
workflow with a blank dashboard
tinydevcrm-dashboard
- [✔] “Sign Up” front-end
- [❌] “Log In” front-end
- [❌] “Forgot Password” front-end (kicking off from MVP)
- [❌] “Confirm Email” front-end (kicking off from MVP)
- [✔] Blank dashboard front-end
- [❌] Python Backend
- [❌] PostgreSQL database
Goals for next week (February 29th, 2020)
- [❓] Add ability to pass custom
className
props to components in order to style them differently depending on the context, and keep fine-grained control of UI display behavior. - [❓] Build out working, full-stack, email-based, token-based
authentication workflow
- [❓] Start Python backend
- [❓] Start PostgreSQL database
- [❓] Wire up front-end to back-end
- [❓] Build out “Data Upload” workflow
- [❓] Build out “View data” workflow
- [❓] Build out “Create Materialized View” workflow
- [❓] Build out “View materialized views” workflow
- [❓] Build out “Schedule Jobs” workflow
- [❓] Build out “View scheduled jobs” workflow
- [❓] Build out “Setup Pub/Sub” workflow
- [❓] Build out “View pub/sub events” workflow
- [❓] Maybe ask close friends to test drive the workflow and see whether MVP can be considered “finished”, before adding process and pushing towards feature parity
Things I've learned
-
Let's talk JavaScript and the
npm
ecosystem. I'd rather use JavaScript or JavaScript-y rather than stray too far in choosing a templated DSL for something like a web-native admin dashboard. For all its faults, JavaScript is a web-native and fully browser-compatible language, and (in my understanding) HTML remains effectively a global markup definition, it can't substitute for some features of JavaScript, like scoping (critical for enterprise-grade state management) or different data types.I'm just so skeptical of JavaScript as a language. Even for a solo developer working on an MVP, I still need an X-to-JavaScript framework like React.js to keep my development velocity high. I don't need a DSL for Python in order to do effective data engineering work. X-to-JavaScript frameworks also don't always sidestep the problem of…JavaScript…and there's no such thing as a lossless translation layer, even one that translates logic to, well, whatever JavaScript is.
Years ago, I lost hope of furthering my career in learning front-end and full-stack development and switched more towards back-end development instead. Issuing read privileges on your work by default vastly complicates things like being paid on time. The fact that you don't own the runtime your client needs means you constantly have to put out compatibility fires. Not to mention the culture of constantly re-inventing the wheel to avoid the existential fact that end-user clients should be disposably cheap and replaceable in the first place, and complicated workflows detract from that goal.
Then there's
npm
and thenpm
culture.For the final version of TinyDevCRM, I want to vendor, audit and package dependencies for myself at a commit-level granularity to verify my ability to support this tool over the long-term builds from scratch using only those audited, vendored dependencies. So with that in mind, I can start a
create-react-app
framework:$ cd /path/to/mydir $ npx create-react-app .
Now take a look at the
node_modules/
directory, and lock all that down manually – nonpm shrinkwrap
or anything fancy like that, don't know where that will be in 50 years.When I run
tree -L 1 node_modules/
, I get"1018 directories, 0 files"
. That's 1,018 dependencies. This iscreate-react-app
, this is the introductory app.Then there's something like
pro-ant-design
, which might mirror enterprise-grade JavaScript workflows better. After running:$ npm create umi myApp
And interactively selecting
pro-ant-design
(that interactivity is by default is not great for systems that are meant to be scriptable, which I've learned is a big pro of CLI-based systems), and runningnpm install
, I get the following output:added 3010 packages from 1366 contributors and audited 3674560 packages in 217.854s 93 packages are looking for funding run `npm fund` for details found 10 vulnerabilities (4 low, 6 moderate) run `npm audit fix` to fix them, or `npm audit` for details
3,674,560 packages for a starter project. There's no way on this Earth I could audit all that myself.
It does look very pretty, and man does this starter project have a lot of functionality that I can use to scaffold much quicker. I'm so grateful that they've chosen to release this as MIT licensed. But sadly, I don't think straight up building from
ant-design-pro
is for me. I'm usingantd
for UI components and I'm open to usingantv
for data visualization tooling.
Again, this is a “if you're so smart, why don't you fix it” kind of question, and I'd rather use React and have that flexibility to do things rather than go without. There's ways in order to package archives using
yarn
's offline mirror capability, which frankly should be fine.Still, this level of dependency bloat and packaging hell remains immensely frustrating for entire classes of projects (like those that need to pass any kinds of serious security certifications, or on-premise deployments). Remember, this is a project built on my own time, with minimal communication needed (since I'm the only stakeholder at the moment). I can't imagine doing something like this while working with other people and under pressure like in a production setting.
-
create-react-app
is actually very nice. You can basically build things usingcreate-react-app
, get to where you want your application to go, and then runnpm eject
in order to ejectcreate-react-app
as a dependency and have custom files you can modify yourself. The more I use it, the more I find it does satisfy the sandbox role it sells itself as.Still don't like the
npm
ecosystem, but I'm gladcreate-react-app
is there to help curate what's good, and provide a sandboxed environment where amongst the constantly changing JavaScript ecosystem and the endless SEO-seeking and sometimes low-effort intro tutorials, you can find good advice just by adding “create react app” to your search query. -
It's incredible how much process and basic functionality I feel like I need to shed. Testing. CI/CD. Documentation. All ruthlessly pushed back from the MVP, to a later stage in the project. At this point, since I don't have anything, it's all bikeshedding. I might be prematurely optimizing some UI/UX workflows (can't help myself) subconsciously as I gnaw on this anxiety. It does seem insane and quite eerie, honestly. I do hope it gets me to where I want to be.