Can you hoist the `if (result)` into the `try` part of the statement? (Without seeing more context hard to know why that wouldn't work for you).
Another pattern to avoid the above is to remember that async functions return promises and that .catch() also returns a promise. So your above logic can be written as:
const result = await funcThatReturnSomeType().catch(doSomethingWithErr);
if (result) {
doSomething(result);
}
Personally I find SQL much easier to read. In a product where you might allow users to write queries it is a much more pleasant UX experience to write and read SQL than it would be to do so for ES queries. It isn't a problem to understand how to build an ES query object but an ES query object is pretty terrible to read IMO.
Duplicate dependencies affecting client side "size" is highly overrated. We can make tools (and have tools) that can compare files for same content and only include them in client side bundles only once. De-duplicating the same could should be a tooling issue. If I want to use client side modules that depend on two different versions of the same library I should be able to do this. Disk space is cheap and we can do the rest via post processing.
Systems where people seem to live under the assumption that if they don't get the latest patch updates or security updates their code will somehow be inferior and they will instantly be hacked. They think that semver will magically solve the problems of having to keep your application dependencies up to date if you want the latest changes/features/fixes.
Pinning in development is equally necessary if you hope to bring sanity to your development team all using the same codebase. Not pinning may be great for a one person 'team' or modules where you control everything, but can be a major time sink when one person is seeing a bug in a patch version they have and another developer is not seeing the same bug because they are on a newer patch. Allowing developers to "clone" consistent versions of the codebase is as important as deploying consistent versions to production.
Why should they reconsider it? Someone that just got into development and might want to show their friends or family something they are hacking away on. According to you they now need to learn about VPS, some random nginx settings or other SSH nonsense and meet some arbitrary "minimal" criteria you have decided upon because that is how you would do it. I think you should reconsider your acceptance of people that don't share your same technological expertise.
To me the ease of having the library be installable with the "canonical" package manager of my platform is too convenient; just "feels" more natural and simpler. I actually thought about writing a node.js ngrok client but then gave up on the idea since localtunnel was working well enough and I personally didn't need the other features from ngrok which I didn't have in localtunnel.
I wouldn't worry about the whole rewrite in c thing. If your server protocol is simple enough, writing clients in the native languages will be better than writing bindings. Installing bindings trips up a lot of users that are not used to compiled software.
I want to clarify why this project exists (as many seem to point out that other projects or methods exist for doing this).
TL;DR; If you think of localtunnel as just a shitty ngrok (or name your project here), you are missing the point and probably don't have the same use cases I do.
1. It was made overnight at some hackathon because I was not satisfied with the other tunneling options I found. They required either an account or some stupid ssh setup. I got to thinking of ways to create a tunnel that simply had an CLI tool and instantly get a tunnel no setup. It worked, I kept it.
2. It is written as a library first, CLI tool second. This means it can be used to create tunnels in a test suite if you want to use services like saucelabs to run browser tests (see https://github.com/defunctzombie/zuul). This is leveraged by projects like socket.io and engine.io (among others). This is perhaps the main reason I keep it around despite there being alternative CLI tools.
3. Both the client and server code are availably and easy to install and use. Companies do this when they want to run their own tunnels for privacy (or whatever their reasons... I don't care).
4. Yes, I know the name is identical to the old ruby?python? one. Whatever. That one seems defunct now anyway.
The generator example has no error handling (at least not from what I can see).
Once the "callback hell" example was re-written with named functions, it is not much different than the generator example and depending on how you are testing, easier to test because it separates out IO from logic (Which you could still do in the generator example).
One thing callback style code has begun to make me think about is the nesting/IO complexity of the functions a I write. When you nest, the IO/event boundary is visible in the code (by the indentation). As you continue to nest, you can start to get a clear idea of the amount of IO being done and where a particular function may be doing too much. Anyhow, most of this is preference anyway :)
As long as every jquery plugin and other code that depends on jquery continues to require all of jquery, all this module stuff is useless. I am sure it helps you organize jquery Dev but it still doesn't help actually define real dependencies on a per component basis.
jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people could use them as needed. No one library is going to provide everything for every project but making everyone require your ajax code when all they wanted was an `offset()` function is equally backwards thinking. We have much better tooling now to work with modules and to reuse code.
Arguments about CDN caching are some sort of premature optimization (or I don't know what really). Most early projects don't need it and other projects can trivially use many of the free (or super low cost) CDN providers if they care that much.
My issues with jQuery are not at how awesome it has worked in the past or how well it has hidden/handled lots of browser quirks; it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. The things jQuery does well would be useful within smaller components or libaries but now we are back to the original issue of jQuery is one giant blob.
This is very unfortunate that they are doing this if the data was scraped and not hitting their servers. Is it that some part of the data they think is copyrighted (like grades) versus just courses?
I run a similar service for other schools (courseoff.com) and I have run into this before. I bet what happened was their site failed to cache the course data or seat information and was thus making lots of requests to the Yale servers. To Yale it might appear like a DoS from this site.
Obviously I don't know for sure but I would venture to bet this block was more an automated response than malicious intent against the site.
You don't have to trust anything. If you want to NIH everything yourself, nothing is stopping you. It is however more likely that many packages on NPM are better than the ones you or your team can create if simply for the fact that they may have been created by a person very versed in the particular domain the package is for. Or maybe it will be shit but whatever :)
Another pattern to avoid the above is to remember that async functions return promises and that .catch() also returns a promise. So your above logic can be written as: