bit-badger/bitbadger.solutions-blog-theme
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

typoz....

Browse Source
This commit is contained in:
Daniel J. Summers 2018-09-03 08:18:43 -05:00
parent 580d123d5e
commit 9ae744eda7
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
source/_posts/2018/a-tour-of-myprayerjournal/conclusion.md
View File

@ -38,7 +38,7 @@ As I tried different <abbr title="Single Page Application">SPA</abbr> frameworks
Then... I ran the build process, and the bundles were huge -- as in, multiple megabytes huge! We changed our implementation of Vue-Awesome to only import the icons we used in the application (to be fair to them, that is the project's recommendation). Element also seemed to be rather heavy. One of the last issues I worked before final release was removing Bootstrap Vue and just using straight HTML/CSS for layout and flow (which is another lesson we'll explore below). There are guides on configuring [Webpack][] to help make moment's bundle smaller (and that project has an open issue to refactor so that it's more friendly to a "just import the part you need" paradigm).
None of this is meant as a knock of any of the fine projects I've named up to this point. It was also near the end of the project when I converted to the Vue CLI v3 template, which uses a version of Webpack that has a much better "tree-shaking" algorithm. (This means that, if it can establish that code is never executed, it excludes it from the bundle.) myPrayerJournal v1.0's modern "vendor" bundle (the one with the libraries) is 283K, while the legacy bundle is 307K; while that's not lightning fast on mobile, it's also comparable to a lot of other sites, and since page updates happen through the API, it is fast once it's loaded.<a href="#note-1"><sup>1</sup></a>
None of this is meant as a knock of any of the fine projects I've named up to this point. It was also near the end of the project when I converted to the Vue CLI v3 template, which uses a version of Webpack that has a much better "tree-shaking" algorithm. (This means that, if it can establish that code is never executed, it excludes it from the bundle.) myPrayerJournal v1.0's modern "vendor" bundle (the one with the libraries) is 283K, while the legacy bundle is 307K; while that's not lightning fast on mobile, it's also comparable to a lot of other sites, and since page updates happen through the API, it is fast once it's loaded.[<sup>1</sup>](#note-1)
**Lesson**: Be smart about what you import.
@ -46,7 +46,7 @@ None of this is meant as a knock of any of the fine projects I've named up to th
## You Might Not Need...
We mentioned above that the site eventually was written with simple HTML and CSS. Many of the more popular pacakges and utilities were created to make up for deficiencies, either in the browser ecosystem or among the differing browser vendors. With the recent efforts by browser vendors to support published standards, though, many of these packages are used for reasons that distill to comfort and inertia. As before, this is not a knock on these projects; they filled a definite need, and continue to work as the basis for a lot of deployed, executing code.
We mentioned above that the site eventually was written with simple HTML and CSS. Many of the more popular packages and utilities were created to make up for deficiencies, either in the browser ecosystem or among the differing browser vendors. With the recent efforts by browser vendors to support published standards, though, many of these packages are used for reasons that distill to comfort and inertia. As before, this is not a knock on these projects; they filled a definite need, and continue to work as the basis for a lot of deployed, executing code.
For new development, though, existing standards -- and their support -- may be sufficient. There are some great sites that detail how certain things can be done using plain JavaScript or CSS.
- [You Might Not Need jQuery][jq]
@ -68,7 +68,7 @@ I used the last one quite a bit. I also extensively referred to [CSS Tricks' "A
> &nbsp; Go would be it.
> -- [with apologies to Baz Luhrmann][ws]
[Go][] is a systems programming language. It was developed at Google, to help them better utilize their hardware. It natively supports concurrent processing (which can be done in parallel, but is distinct from "parallel programming"); has an opinionated code formatter; forces you to address calls that may error; and is terribly efficient. When myPrayerJournal was running with the Go backend, the working size in RAM was around 10MB. Let me say that again, this time with feeling - **the working size for a database-accessing, HTTP-listening, dynamic web service was 10MB of RAM!** If you have ever profiled a web server process, you know that it's nearly ludicrous how small this is. For comparison, the process working set for the F#/Giraffe/EF Core version of the backend runs between 60-80MB, and includes another ~256MB of shared working set memory.<a href="note-2"><sup>2</sup></a> (An Apache2 process running PHP can run in the 256MB range as well.)
[Go][] is a systems programming language. It was developed at Google, to help them better utilize their hardware. It natively supports concurrent processing (which can be done in parallel, but is distinct from "parallel programming"); has an opinionated code formatter; forces you to address calls that may error; and is terribly efficient. When myPrayerJournal was running with the Go backend, the working size in RAM was around 10MB. Let me say that again, this time with feeling - **the working size for a database-accessing, HTTP-listening, dynamic web service was 10MB of RAM!** If you have ever profiled a web server process, you know that it's nearly ludicrous how small this is. For comparison, the process working set for the F#/Giraffe/EF Core version of the backend runs between 60-80MB, and includes another ~256MB of shared working set memory.[<sup>2</sup>](#note-2) (An Apache2 process running PHP can run in the 256MB range as well.)
Why am I recommending a technology that I ultimately moved away from before the v1.0 release? Well, other than "did you read the last paragraph?!?!", the short answer is "it's the future, and will change how you code in every other language." The fact that it forces you to deal with every single thing that may error makes it robust; but, if you learn to develop with it, you will find yourself thinking about error handling more fully than you did before -- and I say this as a person who already coded error handlers as I coded the happy path.