First off, I think the idea and core concept of Workers is awesome. There is so much potential from the security and performance aspect.
I’m no server-side JS expert. So I’ve tried to become more acquainted with the engine, tried to setup a simple but also performant, maintainable and scalable project that could also be used as an App. The experiences I made were rather disappointing. There are some barriers that make developing no fun.
Here are the reasons:
1. Lack of documentation and engine limitations
Initially, I assumed that either frontend code or Node JS code would be fully compatible. However, Workers use the Chrome V8 engine and limit various functions.
eval doesn’t work,
fetch is available, but it is unclear how it works internally. When is which part streamed, when is it buffered? Afaik, there is no complete documentation or library you could refer to. If you write everything manually without libraries, that might not be a problem. However, if you use libraries, we come to the next problem.
2. Building with JS/Webpack is too heterogeneous and complex
I’m rather keen to use or publish libraries than writing everything on my own or copy-pasting snippets. In my view, the separation of concerns supports the security and maintenance of each concern, and product respectively. With Workers, you will need to do one of both if you don’t want to buffer everything and use Regex. I.e., either use libraries (e.g., for streaming, DOM) or copy/paste since chunks are arbitrarily split and may change encodings.
So what’s the problem? What kind of libraries are offered? Essentially, most libraries either support frontend engines, Node JS, or both. Workers, however, have limited compatibility with these libraries, especially streaming-focused libraries. Node libraries often use
net. Frontend ones expect DOMs packages to be available. Ultimately, the most frustrating compatibility issue for me was the streaming package and NodeJS
readable-stream. Even though Webpack should be capable of transforming it, afaik, it doesn’t transform
pipe for me. Rewriting libraries to make them compatible is possible but pointless.
The overall overhead from Webpack is huge. The build configuration is a lot of trial and error. There are libraries that solely push your code beyond the size limit of 1MB. Minifying/Compression is a workaround; the code becomes more difficult to debug, then. Looking forward to the release of Apps with Workers, which requires a code review, I have no idea how that is supposed to work with Webpack code.
What’s the solution?
I might be a little bit biased in this question, but I have worked with various web languages and frameworks. Golang seems to be an appropriate choice as an alternative language to JS. Besides the performance benefits and Golang’s service orientation, it also solves the beforementioned problems. Golang is simple, has little to no overhead when using the standard libraries. The
net/http package makes streaming and modifications of web traffic straight-forward. There is no confusion with API coverage. Libraries can only be incompatible if they are unmaintained; there is no “frontend Golang”; there is only one compiler per version. Compilation could be done server-sided, no post-processing required (such as with Webpack). Dependencies are transparently defined with their full path and versions in every file. One file is sufficient, even if libraries are used. There is a native testing library that can be used for complete
All in all, what I’m trying to say is that I hope for a simpler development solution without the need to trade in either maintainability or performance. Golang would be one approach.