Adjust base href via a NPM package.json scripts

Suppose you wanted to adjust the base HREF in an index.html file using a regular expression, as part of a build process you are cobbling together using NPM scripts. How could you do that? Here’s one answer, though this only works if the sed command line tool is available (as it will be almost always on Linux or Mac, and only if you install it on Windows):

"add-base-url": "sed -i.bak -e 's/\\\"\\\/\\\"/\"\\\/some-base-url-here\"/' dist/index.html",

Unfortunately, I have begged a question. (In the traditional sense and that I assumed an answer to a question, not the modern repurposed thing of the phrase). Is it actually a good idea to use the combination of a regular expression and a script written in a JSON file, to do anything at all?

Looking at the multiple levels of \\/\/\/\\\///\// escaping above, I think the answer to this question is clearly no. It would be better to use some other means for this adjustment. On other projects we have done the same manipulation using a tool that manipulates the HTML structure. It is more verbose but vastly easier to understand.

(Incidentally, I used to do things somewhat like the above to adjust the base URLs for Angular applications.   This is not necessary anymore if using Angular CLI  – it has an option built in, –base-href.)

 

 

TypeScript as ES2015/ES2016+ compiler

I frequently encounter packages on NPM which bring in Babel to compile ES2015/2016+ down to older JavaScript suitable for a wider range of browsers. Babel is a very effective tool for this, it has been around quite a long time, and is highly configurable and flexible in future ready. It has an amazing community and reputation.

But – it is also surprisingly “heavy” in its impact on your tools installation. A typical Babel installation with a typical set of plug-ins can easily bring in 20,000 or more files, spread over hundreds of transitive dependency packages. On a huge project this might not be noticed, but on a small or medium project it can easily be the largest dependency.

Are large NPM dependency trees a problem? Theoretically no, but practically they have some downsides. Dependencies bring risk, and lots of dependencies inevitably bring more risk. If you depend transitively on hundreds more packages, your project is more vulnerable to the sort of NPM vagaries that happen from time to time (the most famous being left-pad), your project is more inclined to fall behind current versions, and most annoyingly in corporate settings, that long list of plugins and transitive dependencies is more likely to cause heartburn among lawyers who evaluate licenses.

There is an easy way to ease this problem, but it involves a minor update to one’s thinkinh. Find the spot in your mind where you may think:

“the TypeScript compiler is a tool for compiling TypeScript code to JavaScript and type checking it”.

The actual truth in 2017 is:

The TypeScript compiler is an excellent, well supported, frequently-updated general-purpose tool very suitable for non-TypeScript users. It does a great job compiling a broad array of standards-path ES2015/16/+ features down to ES2015 or ES5. It fits in well with overall project build tooling. It is completely suitable to use the TypeScript compiler on a non-TypeScript project for this purpose.

The TypeScript compiler has several substantial practical benefits over Babel:

  • It is a single dependency with no transitive dependencies.
  • Usually faster compilation.
  • It is developed by a team at Microsoft, who do a great job grinding away at the boring aspects of this work, shipping a long series of updates which keep fixing bugs and adding features.
  • It installs quickly and has far fewer failure modes in installation (because of no transitive dependencies).
  • Just one open source license to review (no transitive dependencies)… from a company that your company probably already buys a lot of stuff from anyway.
  • Just one version to update, and one configuration file to tweak which features you are using.
  • WebPack and other plug-ins available, quite analogous to Babel.

As of 2017, my recommendation is to consider TypeScript as the default solution for compiling ES2015/16+ code in non-TypeScript projects, and use Babel as a fallback if your project needs cutting-edge features that are (intentionally) not yet in TypeScript.

Cycle JS – example application and video tour

I recently learned a lot about CycleJS, which had been recommended to me in the category “you probably won’t use this for your day job right now, but you will learn a lot by looking”. And indeed, it has turned out to be the case. Cycle can be thought of as an answer to the question “what if we only had Observables and virtual DOM ? Would that be enough to build applications?” It appears to me that the answer is yes, though the tooling is not really all that complete yet.

Along the way I wrote a small example application and recorded a series of short videos (below) explaining some of the things I learned along the way, how to use various Cycle features, and especially about interesting points of comparison between Cycle and Angular and React.

These videos are not an introduction to Cycle, nor do they replace the documentation. Rather the idea is to give a flavor of how things work in Cycle from an application developer point of view, compare and contrast with other approaches, and point out why some of the ideas are quite valuable even if initially not obvious.

As I write this, have recorded four videos and made it about 70% of the way through the example application, talking through how it works and why. Questions and suggestions are much appreciated, probably the best place to put those is in the issue tracker of the example application linked above.

 

 

 

 

Smalltalk

Much of my work (as a technology guru at Oasis Digital) is around the intersection of the most current technology (such as Angular) with existing complex, valuable systems used by our customers. Recently an opportunity came up in which we may interact with some older software written in Smalltalk. I’ve used Smalltalk a bit some years ago, but many of the others at work have not.

To help our team understand a bit about Smalltalk, I demonstrated some of the basics (with Pharo, a surprisingly nice open source implementation) and spoke a while. At the end, someone pointed out that many of the words and the slides might be useful as a blog post for future reference.

What is Smalltalk?

History

  • Advanced technology – from an earlier era
  • http://worrydream.com/EarlyHistoryOfSmalltalk/
  • Smalltalk-76, -80
  • Byte magazine Smalltalk issue – see PDF available online; this issue seemed like sheer magic when I stumbled across it (already worn and tattered) in a library in the mid-1980s.
  • In some ways Smalltalk was decades ahead of its time
  • Descendant of “the mother of all demos”
  • Predecessor of much of what we use today
  • Alan Kay, 1971, “The best way to predict the future is to invent it.”

The basics

  • One of the first OO languages
  • (very) dynamically typed
  • Everything is an object
  • Syntax quite different from most of what we use today
  • Runs on a virtual machine (like JS, Java, .NET, etc.)
  • Contains many ideas that set underneath much of what we do
  • Environment consists of many live objects, developer can manipulate
  • Those live objects reside in an “image”, which can be persisted, shared, deployed

Implementations

Squeak

SqueakJS

  • https://squeak.js.org/
  • Free, open source
  • not what you might guess!
  • Smalltalk VM, run in a browser
  • Not very practical, too many layers of VM

Pharo

  • http://pharo.org/
  • Free, open source
  • Fork of Squeak
  • Generally newer, more polished look
  • Old things cleaned up
  • As far as I can tell, still using the same VM as Squeak, Cog VM
  • Non-native UI, looks quite nice

VisualWorks

Connecting to the world

Source control

  • You don’t write Smalltalk as a pile of files
  • Instead, manipulate classes etc, inside an image
  • Tooling adapts this to a file structure…
  • … when you then can put in source control for collaboration
  • The result is a repository with numerous small files, which maps to and from native Smalltalk code
  • Monticello – let’s look at it.
  • Future thing – Iceberg – use this to understand the image-to-file mapping. https://github.com/pharo-vcs/iceberg

Files

Smalltalk runs in an image, but many/all implementations also provide all the primitives you need to talk to files.

Networks

Many/all implementations also provide all the primitives you need to talk to networks, plenty of protocols, etc.

(server-side) web apps

(single-page) web apps

  • Nothing that I know of, to write these in Smalltalk
  • … but an Angular or other modern web UI could sit on a Smalltalk server

Databases

There are:

  • Drivers for SQL databases
  • Drivers for NoSQL databases
  • Object databases written in Smalltalk

Human factors

Community

There is one. I’m not in it. Who uses Smalltalk today?

Learning more

Thoughts on framing.io

I just participated on the panel for an ngHouston online user group meeting, where Ryan Campbell of BizNas / framing.io presented the Framing framework for complex enterprise Angular applications. You can watch a replay here:

Here is a quick analysis, pros and cons of Framing and its approach. Keep in mind as I write this: Framing has just recently been released and is at the very beginning of working to build a user community.

Pros

Ryan pointed out that, at a certain scale, enterprise teams tend to eventually build something in the general direction that Framing has gone… And he is completely right. Angular’s built-in abstraction for building aggregate of more than one component, NgModule, is still relatively low level, and provides just some low-level structure. It does not provide a pattern to follow around how an application feature could be structured, or other patterns. Teams building large sprawling systems tend to want a more structured way to follow consistent patterns across highly numerous features. Framing provides such a pattern and tooling.

In our work teaching and consulting on Angular, we have met groups who have built things generally like this under AngularJS 1.x, though I don’t think I’ve seen anything similar published for 1.x. Framing is the first thing of its general nature I have seen published for Angular 2+. Actually getting something published is always impressive and worthy of appreciation, there are probably dozens of other somewhat similar libraries/frameworks scattered around the industry, hidden behind firewalls.

Framing appears to have avoided many of the obvious ways that a framework like this could go wrong. There are numerous plug points and overrides available. An application can pick up a feature, and override display strings, data, components use inside the feature, chunks of code used inside the future, and so on. An application can do this without “forking” or copying all of the unchanged code in the future.

Although at first glance it seems like Framing might override the Angular way of doing some things, with a deeper look it seems instead that it provides an additional higher-level, more abstract API for building Angular applications at scale. This API is oriented toward composability and reusability, and a coarse-grained way that the core Angular obstructions are not.

Cons

There are risks, of course. The obvious ones include:

  • Framing might turn out to be 80% good enough but not 100% good enough, and that might be discovered after having built mountains of code.
  • Framing might turn out to be great for a while and then get abandoned, making it to Angular 6 but not Angular 7 for example.
  • Framing might turn out to be completely against the grain of some future change in Angular, such that it really can’t be updated but rather must be re-architected completely.
  • … and more.

Ryan mentioned that there is a path by which they believe they can make Framing fully AOT compatible, but I’m skeptical of this until I see it running. AOT relies on static analysis of the module structure, it’s not perfectly clear that it is possible to perform static analysis of something built this way. (This reliance on static analysis is perhaps the greatest strength and greatest weakness of Angular!)

Framing comes with its own dataflow/reactivity library and approach. This approach might be ingenious, but it is undeniably much less popular and proven than the Redux-flavored design offered by ngrx/store, which seems to be well on the way to “de facto standard” for complex Angular applications.

Learning Angular, learning the many of libraries people typically use with Angular, teaching those things to others, is already a really big challenge. Another additional abstraction like Framing on top, adds to a tall stack of things that have to be learned and taught. This challenge of teaching and learning so much to so many, is already one of the bigger concerns for large organizations (the kind of folks who would benefit from something like Framing) adopting Angular. (Marketing plug: at work at Oasis Digital, we help with the sort of thing, and we teach Angular at Angular Boot Camp.)

Conclusion

Framing is definitely worth a look, and I will follow its ongoing development. I recommend others responsible for sprawling applications do so also.

 

Angular component library AOT

Angular component libraries don’t ship with AOT “ngfactory” output. Why not?

Angular 2-and-up (I’m working with the version 4 release candidate at the moment) is a relatively large and complex single page app framework/library, but unlike some of its smaller competitors it has a key feature to mitigate this and provide a performance boost in deployment.

The feature is “ahead of time compilation”. With AOT, HTML templates used by an application are parsed/compiled during the build process, rather than when they are used in the running application on a web page. This compilation converts the textual templates to TypeScript classes, which are then bundled along with human-written application code. As a result, with AOT large portions of the Angular framework can be excluded from the deployed application.

AOT is typically performed with a command line program “ngc”, in an application build process.

But what about libraries of pre-built Angular components? Should a component library (which might be published as a NPM package, or by some other means) include this AOT output, which takes the form of “*.ngfactory.ts” files?

No – Angular itself does not work this way and build tooling does not support or encourage such a thing. If it did encourage bundling the AOT output libraries:

  • Libraries would not benefit from further improvements to AOT, without also releasing out a new version of the package.
  • AOT would need to generate code which works across version skew, in order to respect semver. this would be a frequent and problematic restriction.

The actual implementation of AOT expects AOT to be performed always at a project level and never at a library level (although the letter is not exactly true; you may use the AOT tool in the library to produce “metadata” files).  With this design, you can consume a library written (for example) with Angular 2.3.3, even if your project is using Angular 2.4.5 (somewhat different AOT output) or Angular 4.x (very different AOT output).