Event review: BrisJs - Introducing the typescript compiler; Atomic design; Scrutinising the norm

I attended the first BrisJS meetup of the year last night. This was my first time attending a “programming language-centric” meetup, and I was surprised to find around 100 people in attendance. All presenters and the majority of the crowd looked to be in their 20’s, and while the presentations didn’t have the level of polish that I would usually expect for an event of this size, I was still able to learn a few things, and more importantly, have some interesting conversations with other developers about projects they are working on and opportunities in the market.

Considering my primary motivation for attending this event was networking and gathering of market intelligence, this post will be relatively short, and will just summarize some brief notes from each session.

Politely intruding on the Typescript compiler for fun and profit

Speaker: Jarred Filmer (BrighTide)

While this presentation was actually aimed at users already familiar with Typescript, and showing how “Ttypescript” (not a typo), can be used to extend the transpiler, I was more focused on the benefits of Typescript itself, especially considering Jarred warned that using “Ttypescript” will not be worth the effort 95% of the time.

Key Takeaways

• Typescript is just regular JS with variable types enforced (i.e String, Decimal, Boolean) when the variable is declared. It transpiles directly to JS, but because of statically typed variables, allows errors to be picked up by the linter or transpiler instead of just running the code and waiting for things to break.
• Using Typescript dramatically reduces documentation required (and repeated), particularly in a large codebase.
• Most people should probably be using Typescript for all but the smallest and most trivial applications - it is simple, lightweight, supported by most major frameworks and makes development much easier.
• Bonus: During the live coding demonstration, Jarred used npx tsc to temporarily install and run a package once only (until now I have been using npm [package] for everything). Very useful for single-time-use packages such as create-react-app.

Component driven development using atomic design pattern

Speaker: Komal Krishna Bandi (Komalbandi)

Anyone who uses a framework such as React will acknowledge the importance of modular design, separating concerns to allow for easy component re-use - but when it comes to actually organising the directory and file structure of the codebase, not everyone agrees how this should actually look.

Atomic Design provides an elegant mental model and practical guidelines for implementing modular component design using the concepts of “atoms, molecules, organisms, templates and pages”.

Key Takeaways

• Komal recommends using Atomic Design for projects of all sizes - while it can initially feel slow and result in what looks like a bloated code structure, the benefits will quickly outweigh this as the project grows.
• Startups love the idea, but for companies with large codebases, the cost of refactoring the code is huge and probably not worth it.
• Some companies prefer to combine “atoms, molecules and organisms” into single items. These companies generally use Storybook to manage their component library.

Maybe you shouldn’t - Why scrutinizing the norm is a must

Speaker: Korey Nunn (KoreyNunn)

A philosophical discussion on the importance of asking “why?”.

Key Takeaways

• Path dependence: 1000 years ago, a cow walked through the bush. More animals followed it’s trail which became a well-trodden path. Humans eventually paved this path. This is now a main road in a modern city.
• On Rocket Ships and Horses Asses: “When NASA designed the booster rockets for the space program, the rockets were assembled in Utah and transported by rail to Florida for launch. Since the rockets had to fit on the existing rail cars, the design of the rocket was constrained by the width of the rail tracks, which in turn had been historically constrained, in a long chain of causation, by the ‘specs’ of ancient Roman horses.”
• Encourage your junior developers to question your reasoning for following a “best practice” or “industry standard”.
• Cherish being wrong - this is how you learn.

Final Words

Thanks BrisJS for putting this on - see you next month.