Skip to content

Commit 3f4c877

Browse files
authored
Merge pull request #1 from cogwizzle/previous-posts
previous-post
2 parents bf3bcc6 + 0b10fcb commit 3f4c877

22 files changed

+1572
-48
lines changed

.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
node_modules/

blog.db

24 KB
Binary file not shown.

config.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
{
2-
"name": "My Blog",
2+
"name": "Cogwizzle",
33
"dbFile": "blog.db"
44
}

content/cplusplus-from-js-dev.md

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
C++ From the perspective of a JavaScript Developer
2+
--------------------------------------------------
3+
4+
My favorite language is JavaScript. I've been primarily developing in JavaScript and Node.js for the past five years with little time spent writing in other languages. I feel like I've become quite proficient in JavaScript and it's complex ecosystem for this reason. I've wanted to dip my toes into lower level languages for quite a while. I decided to go with C++ because for an extremely short time in my career I wrote C as a Test Engineer, and I had some C++ experience in college around the year 2010. What I remembered of C and C++ was struggling with pointers, memory management, and basic data structures. C++, of course is an older language. It does show it's age sometimes. But to my surprise what I found instead was a language that had evolved. Pointers were now a breeze. They had many of the popular features I was using in JavaScript. I just had to figure out where to look. I'll share the secrets I've discovered so far so that any other aspiring JavaScript developers can get their feet wet a bit easier in C++.
5+
6+
### Memory Management - Smart Pointers
7+
8+
Back in college, when I was writing C++ I remember having to clear memory by hand and worrying about the system running away with memory. Many times in college, I got the dreaded core dump message after my terminal locked up. One of the pillars of C++ is that you have low level control to the computer. There is more responsibility that comes with that. The language does not have garbage collection. You, the developer, manage the memory yourself. Let's show an example of what memory management looked like when I wrote C++ before.
9+
10+
```cplusplus
11+
int main() {
12+
Car *p = new Car(); // Create a new car object.
13+
// Do other stuff with car.
14+
p->drive(); // Drive the car.
15+
delete p; // Delete the car from memory when done.
16+
return 0;
17+
}
18+
```
19+
20+
We have a pointer that points at our car object. You generally use pointers whenever a language like JavaScript would've passed something by reference. Then after you do everything you need to do with the car variable you delete the car from memory. A rule of thumb for the older method of using pointers like this is you need one delete for every new.
21+
22+
Fortunately there is a better way of working today. Smart pointers! Smart pointers are a class that wraps around a pointer and manages the memory for you. You can think of them as a pointer that has a destructor. When the smart pointer goes out of scope it will automatically delete the pointer for you. This is a much safer way of working with pointers. Lets see how this looks in C++.
23+
24+
```cplusplus
25+
#include
26+
int main() {
27+
std::shared_ptr p = std::make_shared();
28+
// Create a new car object.
29+
// Do other stuff with car.
30+
p->drive(); // Drive the car.
31+
return 0;
32+
}
33+
```
34+
35+
In the above example we create the same object, but the memory is cleaned up automatically. The way shared\_ptr works is it has an internal counter which keeps track of how many scopes it exist in. Once the counter reaches 0 it runs delete. Note that it does require an unconventional way of creating a car. Instead of calling the constructor you have to call the make\_shared method instead. In order to use shared\_ptr you also need to import the memory standard library.
36+
37+
### Dependency Management - Conan.io
38+
39+
One of the crown jewels of the JavaScript community is NPM. Even though it has it's flaws I believe it is the most successful package management tool on the planet. The JavaScript community should be proud to have this tool in it's arsenal. In C++ package management tooling is not quite at the same level. Due to the way libraries, and packages work in C++ it isn't as easy as in JavaScript to install a dependency. There are a few good options for a dependency manager out there, but the one I settled on was Conan. Conan is a package manager that uses Python recipes to download and build libraries on your local machine. A recipe is a script that tells conan how to configure, build , and make a library available to the developer.
40+
41+
In the same vein of equivalent tooling C++ sort of has an equivalent build system required to make use of these dependencies. In JS we have tools like Webpack. In C++ the most popular build system is CMake. CMake is a build layer on top of standard make that helps you link all of the dependencies and configure your Makefile without writing out very verbose Makefile configurations. I must say that getting started with CMake is very painful in comparison with tools like Webpack, but at least C++ doesn't have as many dialects or toolchains as JavaScript so that makes it a bit easier once you figure it out.
42+
43+
### Lambda Functions
44+
45+
JavaScript is powerful because of the language's ability to be written functionally, or in an object oriented fashion. Being able to pass a function directly in as an argument to a function is very powerful. And this is something C++ can do now. C++ lambda functions were added in C++11. They are a great way to write functions inline. Lets see an example of how this works.
46+
```cplusplus
47+
#include
48+
namespace Test {
49+
auto assert = [](string a, string b) { return a == b; };
50+
}
51+
```
52+
53+
In this example we're creating a function assert that is of the type \`function\`. This takes in two string and returns true if the strings are equal to one another. The array symbols before the parens is sort of like a dependency array in React. Anything you want from the outside scope of the function to affect the internals of the function can be passed into that array, and the values can then be accessed inside of the function. You can also pass \`\[=\]\` instead and everything in the outerscope will be included. Note in order to mutate any of the parameters being passed into the lambda you also need to pass \`mutate\` after the parens.
54+
55+
### Futures - Promises of C++
56+
57+
C++ Also has something called futures which is relatively equivalent to how promises works. It allows you to start a function execution running and continue running other code until you need the value. This is what makes JavaScript so fast. In addition it is a simple way of allowing multithreading in C++ and JavaScript. Here is what Futures look like in C++.
58+
```cplusplus
59+
#include
60+
61+
int main() {
62+
std::future f = std::async([]() { return 1 + 1; });
63+
std::cout << f.get() << std::endl;
64+
return 0;
65+
}
66+
```
67+
68+
In this example you can see that our function f doesn't return a value, but rather a future. This is because the function is running in a separate thread. The get method is what blocks the thread until the value is returned. This is a very powerful way of writing asynchronous code in C++.
69+
70+
71+
72+
I hope this helps some other JavaScript developers get their feet wet a bit easier in C++ without having to do as much reading as I did to find similar features in the language. I'm sure there are many more features that I missed, but I hope this helps you get started.

content/example.md

Lines changed: 0 additions & 3 deletions
This file was deleted.

content/library-bloat.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
Library Bloat
2+
=============
3+
4+
The average size of a web page has been steadily increasing since the beginning of the internet. Over the last few years, with the creation of package registries and package managers like NPM, Yarn, and Bower, the size of our pages has grown at an unprecedented rate. These technologies allow for incredibly fast iteration and deployment of new features and give you the vast array of outsourced tools that you can make use of on your web application. But they come at a cost.
5+
6+
The cost of easy development
7+
----------------------------
8+
9+
So what is the cost of using others' work? Well, it depends on what you're doing. I took a look at the size cost of an empty Create React App shell. While using the built-in Lighthouse feature of Chrome Developer Tools an empty Create React App shell costs 602.3 KiB on a production build and ~1.2 MiB on a development build. That is a lot of JavaScript to display a rotating GIF and a Hello World page. For perspective 1 MiB is a 500-page book's worth of text. Create React App is likely the most common starter for React projects and over half a MiB for a production build is quite expensive.
10+
11+
Let's say we needed to add things on top of our Create React App shell. Perhaps a client-side router? A solution to routing in React is React Router. React Router is a wonderful library. It works well. It has multiple variations on types of routers that can solve the routing problem in many different ways. How much would React Router add to your project? According to the latest build on NPM 672 KiB. You just doubled the JavaScript size of your project by installing a router. I don't know every feature that React Router has, but that is a lot. I did build my own [hash router](https://www.npmjs.com/package/ez-hash-router). It only took me a few hours to write. The hash router's size is only 6.28 KiB at the time I wrote this blog. This site uses that hash router. It seems to solve my problem just fine. I'm sure that React Router is probably an infinitely better solution that solves the problem for 1000 different use cases. If you are like me you probably didn't need to solve 1000 use cases. You just wanted to route your user to specific content in your application. The cost of solving everyone's problem with one tool comes at a cost in size.
12+
13+
Let's take another look at a library that has been popular with the rise of GraphQL. Apollo Client and the React Apollo integration are common libraries used in React-based GraphQL projects. Apollo Client is 3.64 MiB on NPM. The React Apollo integration is 12.5 KiB on NPM. That is crazy large for a library used to send POST requests to a server. You can do that with a 10 line fetch command! To put things into perspective the original Doom is 2.39 MiB of space. The Apollo Client library for retrieving information asynchronously is 1.5 times the size of the original Doom! I'd much rather download Doom than Apollo Client. You might say "Apollo Client has some advanced caching." You are right. It has a lot of features and most of them I don't use (and you probably don't either). I think most of the time I don't need a caching layer. I find myself fighting against caching with Apollo Client twice as often as it helps me solve my problem. It probably slows me down more than it helps.
14+
15+
The list goes on in regards to the JavaScript tools we use and the crazy high size cost it takes to use them.
16+
17+
Who cares?
18+
----------
19+
20+
You may be asking "Who cares if my website takes 5 MiB or 500 MiB to load?" If you have this thought, you are probably a fortunate individual who lives in a place with a fast internet connection. But the truth is a lot of the world doesn't have an internet connection as fast as yours. Imagine if you had dial-up internet and tried to go to a website with a 2 MiB of JavaScript it could take 5 minutes to load on dial-up. If you live in a rural or developing area this is a reality you may live. A good portion of the internet may not be accessible to you because you would likely timeout before the page ever finished loading. You're limiting the reach of your content. That could have an impact on your mission.
21+
22+
What Can You Do?
23+
----------------
24+
25+
**Full disclaimer:** I am part of the problem here. I've created overly bloated sites that have libraries that probably aren't needed. It saved time. Sure, but at what cost. I think we developers collectively can do better. That is a big part of the reason that I started this blog. I wanted to show simple solutions to common problems. I only built the hash router I mentioned before because I wanted to write a website without a modern JavaScript framework and see how the experience was. _(So far, it is great!)_ I love NPM. I think it is the best package manager/package registry ever created. But we should be careful with it and use it as sparingly as possible.
26+
27+
My advice is to be careful when pulling in outside dependencies. Ask yourself if you need the library or if it is a problem you can reasonably solve yourself. If you need the library you can pull it in and use it, but you should always ask the question. I would encourage you to evaluate who the target audience is for you and if you can effectively reach them still with your current solution.

content/you-dont-need-react.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
You Don't Need React!
2+
=====================
3+
4+
You don't need React. This isn't a joke. I'm not trying to make you use another framework like Angular either. Angular is even bigger and you don't need it either. The fact is you don't need a framework at all. I'm just picking on React because it is the most popular and in my opinion has won the Front End library war of adoption. You can just write plain JavaScript. Before you click away please let me explain.
5+
6+
React came at a time when the web specifications were not as far as they are today. Creating your custom HTML tags in JavaScript was an idea largely founded by React and adopted by every framework under the sun. Even the Angular folks abandoned their MV\* approach to adopt a component-based framework in Angular 2+. The idea was foundational to how the web is developed today. I love React too. I have a significant amount of development experience in it. I would even say it is the framework I am most proficient in. But I don't know that we _still_ need it today.
7+
8+
Today's Web
9+
-----------
10+
11+
Today's web has Custom Elements under the Web Components specification. This allows a person to write a custom HTML element with JavaScript, HTML, and CSS. It also comes packaged with a way to register the element to the web page and has a method of encapsulating the element from side effects of the rest of the page's JavaScript called the Shadow DOM.
12+
13+
Right now you may be shouting about how your app needs XYZ library and that React or your Framework of choice has great integration with it. To be honest, you probably don't need that XYZ library either, but even if you do need it, you can still write your app without the React integration. I'm sure the Author wrote the library completely agnostic to that specialized integration.
14+
15+
JSX is so elegant though... I agree but you don't need it though. Writing Components in React should've taught you to write your components very small and to encapsulate the JavaScript and styles from the rest of the page. If you follow these principles in Custom Element construction you also don't need JSX. String literal construction works just fine most of the time.
16+
17+
You could make the jump to lit-element or Stenciljs because they at least compile to Native Web Components, but you don't need those either. The overhead is less than React but is still not required.
18+
19+
Learn JavaScript Not a Framework
20+
--------------------------------
21+
22+
Collectively we need to learn how to write JavaScript, not another shiny framework. I've spent years chasing the Framework dragon. My journey took me from Polymer 0.5 -> RiotJS -> React -> Angular 2.0+ -> StencilJS -> VueJS. I can say that they all work. And they all miss the mark. Polymer just wasn't there at the time. RiotJS never really gained a ton of traction. React oddly decided to break native Web Components by doing some weird synthetic event stuff. Angular 2.0+ will require you to learn how to fly a plane to use. StencilJS is cool but makes you want to write React instead. VueJS is great, but it still has its ecosystem and overhead associated with it. Each one of these frameworks requires a build system and tons of tooling which all take a ton of time to learn and set up. None of them work with each other either. What is the point of creating a component if that component can not be shared?
23+
24+
Native Custom Elements can work in any of those spaces (even React if you're willing to do a bit of work). It requires no build system. You can use it in every modern browser. (Do not say IE11. IE is not modern and needs to die a painful death already). If you spend a little bit of time learning how to write JavaScript and use the new Web Components feature you can save yourself the hassle of learning another framework, all the build tools and prevent your website from becoming obsolete. I'm not the only one who feels this way as GitHub chose to move from jQuery to no framework at all. Everyone else was jumping into React, and Angular forgetting the lessons we learned from moving from legacy jQuery to the shiny new thing. GitHub believed no framework allowed their website to be more resilient over a longer period. They might be right.
25+
26+
Wrapping Things Up
27+
------------------
28+
29+
React is not bad, but it is an artifact that we may no longer need. Facebook built it to solve a very specific problem and I'm sure it'll work for them for years to come. And it may work for your problem too, but you may consider that you don't need it. You probably don't have the same problem they do. Bolting their 2000 pound gorilla to your customer's custom tool may not solve the problem the best way. Try to keep the websites as simple as possible and go as native as possible.

0 commit comments

Comments
 (0)