Reading through Vue.js documentation on “Built-in Components” I learned about powerful tools doing things a Vue application developer could not do on their own. But as a practically matter, I don’t think a beginner like myself would need to worry about them just yet. The same goes for the next section: “Scaling Up”, but I still wanted to skim through to see what scaling problems Vue thought deserved solving. This section was shorter than I had anticipated, because a lot of complexity has been delegated to other tools. These core Vue.js documentation pages would link to their documentation.
The section actually starts small by talking about Vue components and the Single-File Component (SFC) format because that is the basic unit of building large Vue apps. One of the first items is actually a pointer to scaling down via petite-vue for the progressive enhancement (sprinkle tiny bits of Vue in static site) usage scenario. Then it talks about tooling like an extension for editing Vue code in Visual Studio Code, and browser extension for debugging Vue code in browser.
The topic then moves to testing. Generic web application testing frameworks would work, but the Vitest test runner is optimized for unit testing Vue components. Once we get beyond unit tests, there’s a pointer to Cypress and a link to a Vitest vs. Cypress comparison.
For client-side routing, documentation gives a simple router implementation and a reference to Vue Router for a full power routing solution. For state management, we again have a simple implementation and a reference to Pinia for a more complete solution.
Server-side rendering (SSR) can get very complex, so the discussion started with the very important question: do we really need it? Sometimes goals can be satisfied with static-site generation (SSG) in which case we can use VitePress. But if actual SSR is required, there are multiple paths depending on the developer’s desire for control. Higher-level tools include Nuxt.js, which can also do static-site generation. And Quasar, which proclaims PWA capability as well as compiling to mobile apps and browser extensions. Plus it features its own Material Design compliant UI components, making it appear to be the “and the kitchen sink” solution. Which, depending on the project, may or may not be a fit for following best practices.
While reading Vue.js documentation on reusability, I learned of VueUse library filled with composable code available for use in our Vue apps. With that in mind, I was curious about the next section of documentation: “Built-in Components.” What’s special about these components? They must enable features requiring internal Vue support and could not be done (at least not efficiently) by an external code module. From what I can tell, they have one thing in common: they hook into platform changes to component structure.
First example supports transition animations. CSS defines a transition animation mechanism but that only applies to changing properties on an object. Animating the objects themselves being changed requires support like Vue’s <Transition> for individual components and <TransitionGroup> for elements in a list. By default, adding or removing components from the application means an abrupt and instantaneous change that may leave the user disoriented. These components allow designer to add transition animation to visually guide the user through such changes for a better user experience. Both by adding/removing classes to trigger CSS transition animation plus JavaScript hooks for whatever can’t be done via CSS.
An example of a feature that requires framework level support is Transition Mode, which manages how the old and new components interact to mitigate visually jarring artifacts. Moving from “mitigating a bad thing” to “enabling a great thing” is the Move Transitions demo for <TransitionGroup>, a great way to visually inform a user of changes in a list. After seeing that, I’ve become a fan of <Transition> / <TransitionGroup>. Sure, they can be abused just like all mechanisms designed to attract user attention (Die <blink> Die) but there’s plenty of room for subtle and tasteful designs. On the downside, I’m not a fan of Named Transitions which introduces more name magic to Vue.
In the spirit of Vue keeping things lightweight and not reinventing wheels, <Transition> / <TransitionGroup> only enables transitions, they do not define any animations themselves. This page links to animation libraries (Animate.css, GreenSock, Anime.js, Motion One) that it plays well with.
As much as I love some of the animations demonstrated here, as a practical matter I’m not likely to use any of these directly in the near future. If I start building projects with Vue, I’ll start without worrying about visual polish. For a first pass on visual polish, I’ll probably use something like Vue Material. Crafting my own visual styles with transition animations will be much further down the line, if ever.
I’m equally unlikely to use anything else in Vue’s “Built-in Components” section. <KeepAlive> keeps a <component> node alive to keep its state, in the expectation of eventual reinsertion back into the tree. <Teleport> moves visual elements somewhere outside of their proper location in Vue component hierarchy, useful for global model display dialog boxes. And <Sense> is still an experimental feature for consolidating visual feedback of multiple child asynchronous operations. (One spinning “waiting” animation instead of each component having their own.) <Sense>combined with<Transition> and <KeepAlive> to handle Vue Router changes is far too advanced of a technique for this beginner to worry about.
Which is true of most of the rest of Vue.js guides, but I wanted to skim over them anyway starting with “Scaling Up”.
Vue’js documentation’s “Components In-Depth” section gave me a pretty good idea of how Vue components are implemented and interact with each other. It’s a powerful mechanism of code organization and reuse, and I found it strange Codecademy’s “Learn Vue.js” course didn’t go into any details on componentization at all. Still, as useful as Vue components are, they can’t do everything and there are a few other mechanisms for code reusability in Vue.js. After reading “Reusability” section, my takeaway is that a beginner should know how to use these mechanisms: both to recognize their presence in example code and benefiting from work shared by others. In contrast, implementing these mechanisms is a more advanced topic a beginner can postpone until later.
The most significant page in this section is the first one: Vue Composables. These are self-contained packages of pure logic without a visual representation. In that regard it has some resemblance to Angular services but more limited in scope (which probably also means it is lighter weight.) It is possible to implement composable capability as a standard Vue component with no visual template (renderless component) but that incurs wasted overhead. For an even better idea of how a composable relate to other code reuse mechanisms, there’s a comparisons section on this page.
I was most fascinated by the async state composable example, because it seems to be a way to solve many of the problems RxJS wants to solve but with less of a learning curve. Also, this is optional versus RxJS which is required to make real use of Angular. But if we really want RxJS, there exist Vue composable to interoperate with RxJS. It is part of VueUse, a collection of Vue composition utilities that cover a lot of ground. I see stuff to help with concepts like an app going full screen, an app that wants to keep the device awake, and to help an app communicate over web sockets. Some of these aren’t terribly complex to implement on our own (like full screen) but using one of these composable component might be even easier.
Following the long and instructive page on Vue composable, there were two more pages far shorter in length. First is custom directives, a mechanism for installing and using code that needs direct low-level HTML DOM manipulation. It reads like a niche tool useful as a tool of last resort for things that can’t be done any other way. The page ends with “In general, it is not recommended to use custom directives on components.” And second page covers plugins, a mechanism to install functionality at the app level. We are warned to use plugins sparingly as too many of them start running into name conflicts and other general downsides of global code. This is partly because a plugin interacts with the rest of the app via non-plugin-specific mechanisms like Provide/Inject, custom directives, and attaching to global properties (app.config.globalProperties). The example on page shows two ways to do internationalization string plugin: attached to global properties, and provide/inject.
That’s a lot of different ways we can package Vue code to be reusable, but they’re limited in how they can participate in framework-level activities. For those, we need to use Vue’s built-in components.
Vue.js documentation “Essentials” section ended with a page on “Component Basics”. That lead to the next section “Components In-Depth” covering more details on how and when to use Vue.js components and how they interact with other components in the app. After reading the section, a few items caught my attention that may or may not be significant once I start getting hands-on with Vue.
Naming
Names for Vue.js components are PascalCase by convention but that has problems with using them in HTML attributes that are liable to coerce everything to lowercase. The same problem applies to Vue.js events which are camelCase by convention. Vue.js includes magic to look at equivalent kebab-case names. I guess it solves the problem but seems like a source for future problems. What if multiple cased versions exist in code, which one runs first?
Name collisions could also happen due to a feature called “fallthrough attributes”. A component with its own “click” could have another “click” fall through from above. Which one has priority? A declared emitted “click” handler would override native “click”. A fallthrough “click” and an emitted “click” would… both be called? Wild.
I like that Vue.js works to magically fix up these kinds of problems, but I’m uncomfortable magic renaming mechanisms exist. Historically they were a high risk for bugs.
Props and Events
Props are intended to be one-way, from parent to child. But because it’s valid to pass objects, a child can modify those object instance and potentially change parent state. For performance reasons, Vue doesn’t try to detect or prevent such “deep change”. Documentation boils down to “Don’t do that” though it did describe a few potential scenarios and their workarounds. The right way for a child to communicate with parent is with emitted events, which are raised only on its direct parent.
Props go from parent to immediate child, emitted events are raised from child to immediate parent. Going beyond that (communicating across multiple layers in the hierarchy) could get messy. I saw mention for one mechanism called State Management, which will be covered in the “Scaling Up” section. There’s also the Provide/Inject mechanism, which isn’t exactly the same as Angular services but has a few similarities. To make them properly reactive values require computed() which is normally just for Vue.js Composition API. To read more about computed(), we are instructed to go back and read certain documentation sections while set to Composition API and not Options API.
Props can have default values when not assigned by parent and/or marked as “required”. To help keep objects well-behaved, we can validate values for props to ensure information coming in to a component is within expected range. We can also validate events, which isn’t a mechanism that shows up very often. Usually, events going out are assumed to be within expected range because it was generated within that component. Or maybe I’m misunderstanding the Vue.js mechanism.
Going Bigger
As mentioned earlier (in the context of state management) there’s an entire section dedicated to scaling up to larger and more complex projects. But we do get a preview of several mechanisms because they rightly belong in “Components In-Depth”
One item I had wondered about upon learning v-model was how that would work across component boundaries. The short version: Either (1) bind to a native input component inside the custom component template, or (2) bind to a writable computed value with getter and setter.
I think I have a good grasp of slots, but not scoped slots. It took me three readings to understand it is a (convoluted at first glance) way for information to cross parent/child component boundary. This will definitely take several rounds of hands-on practice (and painful debugging sessions) to master.
Symbols keys were brought up as a way to avoid Provide/Inject naming ambiguity in large projects because they potentially have global scope. This is the first I remember seeing symbol keys, I expect to get more information about it elsewhere in documentation.
Vue.js apps that grow big enough to worry about download size can split components off to be loaded asynchronously on demand. Vite recognizes this mechanism as a breakpoint for bundling purposes. I have yet to come across its Angular counterpart. Possibly lazy loading?
I went through a short tutorial on Vue.js site and found it to be a succinct overview. It doesn’t go very deep in any single topic, instead introducing a breadth of Vue concepts with links for deeper reading. The recommended step to follow that tutorial is the documentation section labeled “Essentials”. It was instructive reading and some items I found notable were:
HTML
Vue.js essentials logically started with Creating an Application where I was happy to learn HTML is at the forefront acting as I thought markup should. An Vue application instance mounts to an element on the page. This is in contrast to Angular (and what I understood of webpack) where JavaScript is at the forefront and primary job of index.html is to load that JavaScript. It has almost no content of its own.
Because of this, innerHTML markup on Vue-bound components can act as template for that component. Which is convenient, but I wonder if there’s a way to have fallback text to show the user before Vue loads. Or if Vue fails to load because the user turned off JavaScript in their browser.
Another effect of this architecture is that it’s valid to have multiple Vue applications on a single page, each mounted on a different HTML container element. I don’t think I can do this with Angular, which I’ve only ever seen control the entire page.
Or maybe I can mount no Vue application at all? I don’t understand the nuts and bolts yet, but it seems feasible to let the markup load quickly for the user to see. And sometime after that, mount Vue components as needed.
A downside of this approach is that Vue might have stuffed too much into the HTML file. One example is Vue dynamic arguments, which look just like HTML attributes to the browser and is liable to get coerced to lowercase by browser’s parser causing “name not found” errors.
Reactivity
The Reactivity Fundamentals section was the first Vue documentation section where I saw large differences between Vue’s ‘Options API’ and ‘Composition API’ variations. Using options API means letting Vue handle everything behind the scenes, but using composition means the author has to be aware of what goes on behind that curtain and have to correctly participate in the process.
A core part of Vue 3 is the use of JavaScript proxy around component data so Vue knows when data has changed and need to react accordingly. Some notable side effects are that this pointer behaves slightly differently. We should avoid arrow functions and avoid tracking state outside of data. If we inadvertently share static data across instances, that will become a source of problems.
The reactivity infrastructure leads to a significant difference between computed properties and methods. Computed values are updated only when their reactive dependencies (through their proxies) are updated. This allows performance optimizations like returning a cached value rather than running the computation again. In contrast, methods are always called.
Compared to Angular, Vue’s reactivity system is much more constrained in scope. Nothing like Angular’s use of RxJS, which was its own big sprawling thing.
Components
The Vue Essentials section ends with Component Basics which lived up to its name covering the very basics of Vue components. Enough for us to understand how the various concepts tie together, even if we don’t understand them in detail just yet. For those that want to get deeper, there are plenty of links for more details.
Communication between components and their parents are usually handled in one of three channels: (1) Hosts can set value on a component’s props. (2) Component can emit events to handlers on the host. (3) Host can send template fragment via slots. Hosts can dynamically control what components are loaded with <component> which seems like a very powerful tool, illustrated with a simple tabbed interface where each tab is a different component.
Compared to Angular, I didn’t see a mechanism for code to interact with components beyond parent-child relationships. The good news is that there’s no counterpart to the headache of Angular service registration and injection. The bad news is that I don’t know how to get similar functionality in Vue. [UPDATE: I found Vue’s Provide/Inject.]
Infrastructure
Vue Playground is used for live code examples that we can play with in the browser. It seems to be an openly available tool, I didn’t see any restrictions constraining it to Vue documentation examples. This is a very promising option for experimenting with Vue concepts hands-on later.
At several locations, there were links to video courses on Vue School. Normally, I’m not a fan of video instruction but perhaps I should at least try a few of their free courses to see how well I can learn. The bar is high: it needs to be pretty impressive for me to start paying a subscription!
After a brief detour exploring Vite’s support for legacy browsers like IE11, I returned to learn more about Vue.js from its own tutorial. Vue advertised itself as flexible in many ways and this is immediately visible on the first page of the tutorial: in the upper left corner we have two choices to make. Options vs. Composition API, and HTML vs. SFC format. Combined, it implies the tutorial can show us how to use Vue four different ways and would be a great resource for some direct comparisons.
SFC format integrate a component’s HTML template, CSS, and JavaScript/TypeScript all in a single *.vue file. These files are processed by a build-time tool like Vite to generate files actually going into a browser. In contrast, the HTML format is intended for using Vue without build tools. All of Vue is linked from the HTML and all script lives in the HTML as well for direct browser consumption.
Options API is the format used by Codecademy’s Vue.js course as well. It imposes a particular organization to Vue component data. Composition API does not impose such structure and so the JavaScript can be organized however you like but it also comes with requirement for managing overhead we wouldn’t have to worry about with Options API. In terms of expressive power, Options API is implemented using Composition API. Meaning anything we can do with Options we can do with Composition, but the reverse is not necessarily true.
For my first pass, I will leave things at default recommended for Vue beginners: Options API in SFC format. This tutorial is very short, with just 15 sections. Or more accurately 13 sections when accounting for the fact not much material is covered by the first page introduction or last page conclusion. The implementation structure is an in-browser learning environment similar in concept to Codecademy’s learning environment. The upside is that we don’t have to set up a local development environment, the downside is that we don’t get to see how a Vue development environment would look.
Vue’s tutorial covers a few important concepts with some overlap with Codecademy’s course (interpolation, directives, data/computed/method/watch) and some areas are different. It didn’t get into forms as Codecademy did, but did get into componentization, lifecycle hooks, and props/emits/slots which Codecademy’s course did not.
Both of those are shallower and more superficial than something like Angular’s “Tour of Heroes” tutorial, which went into far more depth starting with setting up a local development environment. If I want a Vue tutorial with that level of depth I will have to look elsewhere. Still, they were instructive and I’m glad I’ve gone through both Codecademy’s course and Vue.js tutorial. They prepared me to go deeper with Vue documentation starting with the “Essentials” section.
One tangential item I learned from this tutorial is the site https://jsonplaceholder.typicode.com/ for a publicly accessible free static mockup of generic API endpoints returning ipsum lorem data. This could come in handy for my own experiments in the future.
While looking over Vue.js’s Quick Start example, I noticed its default set of tools included Vite. I understand it plays a role analogous but not identical to webpack in Angular’s default tool set. I found webpack’s documentation quite opaque, so I thought I would try to absorb what I can from Vite’s documentation. I still don’t understand all the history and issues involved in JavaScript build tools, but I was glad to find Vite documentation more comprehensible.
The introductory “Why Vite?” page explained Vite takes advantage of modern browser features for JavaScript code modules. As a result, the client’s browser can handle some of the work that previously must be done on the developer machine via webpack & friends. However, that still leaves a smaller set of things better done up front by the developer instead of later by the client, and Vite takes care of them.
In time I’ll learn enough about JavaScript to understand what all that meant, but one section caught my attention. Given Vite’s focus on leveraging modern browsers, I was surprised to see “browser compatibility” section included an official plug-in @vitejs/plugin-legacy to support legacy browsers. Given my interest in writing web apps that run on my pile of old Windows Phone 8, this could be very useful!
I opened up my NodeJS test apps repository and followed Vite’s “Getting Started” guide to create a new project using the “vanilla TypeScript” template preset. To verify I’ve got it working as expected, I built and successfully displayed the results on a current build of Google Chrome browser.
Then I added the legacy plugin and rebuilt. It bloated the distribution directory up to 80 kilobytes, which is a huge increase but still almost a third of the size of a blank Angular app and quite manageable even in space-constrained situations. And most importantly: yes, it runs on my old Nokia Lumia 920 phone with Windows Phone 8 operating system. Nice! I’m definitely tucking this away in my toolbox for later use. But for right now, I should probably get back to learning Vue.
The first difference is here we’re creating an application with Vue.js, which means firing up command line tool npm init vue@latest to create an application scaffolding with select features. Since I’m a fan of TypeScript and of maintaining code formatting, I said yes to “TypeScript”, “ESLint” and “Prettier” options and no to the rest.
I then installed all the packages for that scaffolding with npm install and then I ran npm run build to look at the results in /dist/ subdirectory. They added up to a little over 60 kilobytes, which is roughly one-third built size of Angular’s scaffolding. This is even more impressive considering that several kilobytes are placeholders: about a half dozen markup files plus a few SVG files for vector graphics. The drastically smaller file sizes of Vue apps are great, but what have I given up in exchange? That’s something I’ll be looking for as I learn more about both platforms.
Poking around in the scaffolding app, I saw it demonstrated use of Vue componentization via its SFC (Single File Component) file format. A single *.vue file contained a component’s HTML, CSS, and TypeScript/JavaScript. Despite the fact they are all text-based formats and designed to coexist, I’m not a fan of mixing three different syntax in a single file. I prefer Angular’s approach of keeping each type in their own file. To mitigate confusion, I expect Vue’s editor tool Volar would help keep the three types distinct.
Some Vue components in the example are tiny like IconTooling.vue which is literally a wrapper around a chunk of SVG to deliver a vector-graphic icon. Others are a little more substantial like WelcomeItem whose template has three slots for information: #icon, #heading, and everything else. This feels quite different from how Angular components get data from their parents. I look forward to learning more about this style of code organization.
I’m far from an expert with the Angular web app framework, but I’m itching to look around. Use what I’ve learned of Angular as a baseline to compare design tradeoffs against those made by other web app frameworks. I thought Vue.js was worth a look, and I’ll start with Codecademy’s “Learn Vue.js” course. It was very short and really didn’t cover very much of Vue.js at all.
The good news is that learning Angular helped introduce many web app framework concepts, making this Vue.js lesson easier to understand despite its short whirlwind tour format. When it came to Vue directives, I can immediately see similarities between Vue’s “v-if” and Angular’s “#ngIf“. v-for and #ngFor, etc. A novelty to me was the concept of directive modifiers which are shorthand for calling common methods. v-on:submit.prevent is an event handler for a form “submit” event, and appending “.prevent” means Vue will also call Event.preventDefault(). Something many event handlers would do but, with the modifier, they won’t have to explicitly do so.
One area this course skipped, probably in the interest of keeping things simple, was by using Vue as a single monolithic CDN-delivered package. Bypassing the entire build/bundle process. Initially I thought “yikes” at how large the result must be. Until I looked at the download size of vue.global.prod.js and saw all of Vue weighed in at just 128 kilobytes, almost half the size of a tree-shaken, minified, optimized production build of Angular app boilerplate. And it can be further GZip-compressed down to 48 kilobytes for space-constrained places like ESP8266 flash memory. OK, that’ll work!
Half the course (two out of four sections) focused on building forms with Vue. This was unfortuate for me personally because I never really dug into doing forms with Angular, so I couldn’t make a direct comparison between those two frameworks. I read enough about forms in Angular to learn that there were two different ways to do it. I didn’t know enough to choose between them, so I never did either.
Still, building forms allowed us to cover a lot of general ground about using Vue. It let us see how Vue wanted our code to be organized in one gigantic object passed into the constructor. (I would later learn this was the “Options API” approach, the alternative “Composition API” was not covered in this Codecademy course.) We have data properties, computed properties that calculte based on data, watchers to act in response to data changes, and methods to for everything else not directly llinked to a property. It seems like a better structure than a wide-open JavaScript class, especially for components with a tight focus.
The fourth and final section covered doing CSS in Vue. I was quite wary of this section, as I’ve read some complaints about CSS delivered by JavaScript code at runtime. It means the browser rendering engine has no opportunity to preview and preprocess those CSS rules before the JavaScript code inserts them, a pattern which can have disastrous impact on rendering performance. What this Vue.js course covered isn’t quite the full-fledged “CSS-in-JS” (which has its own Codecademy course) but I’d still be cautious of using v-bind:style. On the other hand, v-bind:class seems like less of a danger. In this approach, the browser gets to process CSS beforehand and we’re toggling application on and off via JavaScript code. I’m more inclined to go with v-bind:class.
And finally, I was looking forward to seeing how Vue handled componentization and I was very disappointed to see it was considered out of scope of this course. I think it’d be instructive to see how Angular components compared to Vue components, maybe see how they compare to LitElement, and how they compare to standard web components. Well, I won’t find any of those answers here because the course mentioned componentization as being very useful and never got into how to do so! I’ll have to look elsewhere for that information.
Having an old Windows Phone 8 die (followed by dissection) was a fresh reminder I haven’t put enough effort towards my desire to “do something interesting” with those obsolete devices. The mysterious decay of one device was a very final bell toll announcing its end, but the clock is ticking on the rest of them as well. Native app development for the platform was shut down years ago, leaving only the browser as an entry point. But even that browser, based on IE11, is getting left further and further behind every day by web evolution.
In one of my on-and-off trips into web development, I ran through Angular framework tutorial and then added legacy project flags to make an IE11-compatible build I could run on a Windows Phone 8. That is no longer possible once Angular dropped support. One of the reasons I chose Angular was because it was an “everything included, plus the kitchen sink” type of deal. An empty Angular app created via its “ng new” command included all the tools already configured for their Angular defaults. I knew the concepts of tools like “bundler”, “minimizer”, etc. but I didn’t know enough to actually use them firsthand. Angular boilerplate helped me get started.
But the reason I chose to start with Angular is also the reason I won’t stay with it: the everything framework is too much framework. Angular targets projects far more complex and sophisticated than what I’m likely to tackle in the near future. Using Angular to create a compass web app was hilarious overkill where size of framework overhead far exceeded size of actual app code.
In my search for something lighter-weight, I briefly looked into Polymer/Lit and decided I overshot too far into too little framework. Looking around for my Goldilocks, one name that has come up frequently in my web development learning is Vue.js. It’s supposed to be lighter and faster than Angular/React but still have some of the preconfigured hand-holding I admit I still need. Maybe it would offer a good middle ground and give me just enough framework for future projects.
One downside is that current version Vue 3 won’t run on IE11, either. However, the documentation claimed most Vue fundamental concepts haven’t changed from Vue 2, which does support IE11 and is still on long-term service status until the end of 2023. Maybe I can get started on Vue 3 and write simple projects that would still run on Vue 2. Even if that doesn’t work, it should help orient me in a simpler setup that I could try to get running on Windows Phone 8.
I’m cautiously optimistic I can learn a lot here, because I saw lots of documentation on Vue project site. Though that is only a measure of quantity and not necessarily quality. It remains to be seen whether the material would go over my head as Lit’s site did. Or if it would introduce new strange concepts with a steep learning curve as RxJS did. I won’t know until I dive in.
I enjoyed exploring leading edge web development with experimental features like magnetometer API and evolving standards like PWA. But learning about the trailing edge also has some value for me. I have a stack of old Windows Phone 8 devices. Microsoft had shut down native app development for the platform as part of its end-of-life treatment, leaving its onboard web browser as the only remaining entry point. Based on Internet Explorer 11, support of which has been dropping from platforms left and right, there’s definitely a clock ticking away if I want to be able to do anything with those phones.
Assuming, of course, those phones don’t decay and die on their own like this Nokia Lumia 520 has done. It’s been a guinea pig to test things like ESA’s ISS tracker web app. When I turned it on recently, it failed to boot and crashed to this blue screen of death. Unlike its desktop Windows equivalent, there are no debug information printed onscreen. Documentation has been purged from Microsoft and Nokia websites as they have disowned these devices. So, it was up to iFixit to preserve documentation on performing factory reset with a hardware key sequence: From powered off state, hold [volume down] and press [power] to start phone. As soon as phone vibrates, release [power]. Once phone boots to exclamation mark, release [volume down]. Press key sequence [volume up], [volume down], [power], [volume down]. Watch spinning gear onscreen for a few minutes.
But performing such a reset on this phone didn’t help, I just ended back at the sad faced blue screen of death. I don’t know what happened to this phone. I hadn’t thought electronics would decay with time, but something on this one has failed in a way I lacked information or tools to diagnose. I powered up my remaining Windows Phones and they were able to boot, so it’s not a common/widespread failure mode. (Yet?) In any case, today this dead phone gets the teardown treatment.
Nokia Lumia 520 was a simple and basic entry-level phone, dating back to the era when batteries were easily accessible and removable by the user. Not so much anymore, which is sad though there are occasional encouraging signs. Popping off the easily-removed blue back cover, we see physical features like a microSD card slot, SIM slot, and headphone jack. All useful features disappearing from modern phones.
The next layer is a black plastic cover held by multiple Torx fasteners and plastic clips. Removing that cover exposes phone mainboard, where we can see the thickest component is the rear-facing camera. It actually sits in the middle of a hole cut out of the circuit board, protruding both in front and behind of the board. (Lumia 520 does not have a front-facing camera.)
Ribbon cable near the top of the device is for touch digitizer input via this Synaptics chip.
Synaptics
S22028
33120155
ACAN310
Sadly, a web search with engraved text failed to return anything useful.
The touch controller communicated with the rest of the phone with ten wires, but they are far too fine-pitched for my current skill level to work with.
It’s a similar story with the LCD, connected to mainboard with twenty wires. Far too few to directly control an 800x480x3 LCD array, these must be data buses communicating with a controller somewhere downstream. At least six of these wires visibly hint at differential signal pairs.
Front and back views of removed mainboard. Full of tiny components, most of which hidden under RF shields, I see only two components (battery connector and vibration motor) that I could realistically repurpose.
With mainboard removed, I see no further fasteners to remove, and no obvious seams.
I knew it was too complex to be a single piece, so I manually twisted the assembly looking for signs of seams between parts. Attacking candidates with iFixit picks allowed me to separate the front panel touch digitizer from display subassembly.
The display assembly is held to its chassis frame with a few strips of adhesives and could be carefully peeled apart.
Freed from its structural frame, the display assembly feels very delicate. It easily flexes and twists to reveal details like these side-emitting LEDs for backlight illumination.
Peeling back foil tape uncovered ultra fine-pitched LCD array control wires embedded between layers of glass.
Trying to separate LCD array from backlight, I unfortunately cracked the glass and destroyed the LCD. I might be able to reuse the LED backlight but it’s going to be a serious challenge finding (and soldering to) those fine wires for LED power.
Goodbye, Nokia Lumia 520. I’m sad I didn’t get around to finding something interesting to reuse you as a whole unit. And your component parts are mostly too tiny for my current skill level to work with. But your death gave me a kick in the pants to get on with my studies. I hope to make use of your surviving contemporaries.
New Screwdriver 