TinyDevCRM Update #2: Front-end Shenanigans

Posted on by Ying Wang 6 mins read

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

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 the npm 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 – no npm 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 is create-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 running npm 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 using antd for UI components and I'm open to using antv 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 using create-react-app, get to where you want your application to go, and then run npm eject in order to eject create-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 glad create-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.

Subscribe to my mailing list