Looks very nice! It almost made me want to learn Swift.
The only thing is that it's used only on iOS systems. If I'm going to spend the time to learn a new programming language, I'd like to use it everywhere like I do with JS.
Thanks. So, for this to work, I have to enable iCloud Drive on both machines? Looks like it takes quite a long time to upload 375MB playground files to iCloud too.
> The only thing is that it's used only on iOS systems.
It's also used on the macOS, which is kind of the point of this HN posting.
In the magnitude of using a given platform, learning the language is a small part; the APIs and tooling will be a larger effort. If you already know those things for the iOS, the jump to macOS will be less.
Swift can be compiled and run on Linux. It's most prevalent on Apple platforms. It's usefulness outside of the Apple platform is a different topic though.
I suppose Swift is like a CLR language (e.g. C#) in that sense, then? The language itself will run in many places, but most of the library bindings anyone might care about, or want to use the language to get access to, are for platform-specific libraries.
For what it's worth, C# is very usable on both Linux and macos. Anything outside of UI is pretty much fully cross platform at this point (there are even some cross platform ui attempts, but they're not anywhere near as mature as wpf, xaml, winforms, etc)
These days there’s been a lot of movement towards cross platform C#, with .NET core etc. Whilst there isn’t any desktop application support (other than Xamarin), there’s a good ecosystem for ASP.NET.
You may just want to learn a touch of swift to experience nifty language features such as optionals. (Unless you have worked with languages that have all of swift's nifty features)
More than a few, it's quite ridiculous so many devs are sniffy about it. If you can handle cpp, you can handle swift, one of my biggest gripes right now is having to deal with a cross platform cpp solution that just seems to throw out 10 years of progress so they can implement code like they're used too and reimplement built in solutions slower and harder to work with.
This always puzzle me about SEO. Let's say you are writing an article that you want to cover in-depth. Which one is better for SEO (both options has the same content):
A. Publish all in one long article
B. Publish in a series of small articles
The goal is to answer the question or problem as best as you can.
Typically this means not just giving a one line answer, but expanding and elaborating, going into relevant details and explaining more in-depth.
Often this extra detail will overlap with extra detail from other questions. You can link between articles, but you can also rephrase / repeat ideas.
eg. If you're searching for "Redirect in javascript" or "Simulate link in Javascript", you'll want two separate articles.
You know that the answer is the same for both, but the searcher doesn't. And as you go more in-depth explaining how `window.location` works, you'll end up covering similar material in both articles (which is not duplicate content so Google won't penalize you).
This is awesome! I started using Tailwind for a project. I was a concern with the relatively big size of the framework on a landing page[1]. Then I used purgeCss to only leave the css classes that I used and remove all others. That solved the size issue.
Is there any purgecss equivalent, that is a local tool and is not node.js? I've recently searched for that and only found a defunct Ruby gem. Does the Golang world have nothing like that?
Because it's yet another full ecosystem with lots of dependencies where I have zero knowledge and experience.
For example, all those packages say "npm install packagename" to install, but it didn't work for me. It seems I have to (sometimes?) do a "npm init" first. No install instructions ever tell you that.
I'm sure when you're in the ecosystem, that's a given. For me it's hurdle after hurdle.
That's why I named Go and Ruby as examples. The former because you usually get a standalone executable, the latter because I already have that toolchain installed, and I know how to navigate it.
Unfortunately, everything in webdev is now node.js. Just look at any CSS framework docs (including Tailwinds, which I really like): it's an endless stream of pre-processors and post-processors, multiplied with all kinds of ES versions, Babel, yarn-or-npm, this build tool or that. It just doesn't end.
I've been using NodeJS for about 5 years and have never seen the init usage you're talking about. `npm init` initialises your new project. At least I think that's the case, because I've never run that command. I just create a package.json file myself. Also, I use yarn instead of npm. But of course, because change, there is now a new way to use init that you just alerted me to. It sure seems like an unnecessary complication. I recommend using yarn, by the way.
I read the first part of your comment and thought "okay, I expected that I probably misunderstood the init thing".
Nothing to feel bad about, as I said, I'm an outsider, but still annoying to get it wrong in my comment.
And then I read the second part and am simply astonished. I wasn't wrong? I just happened to stumble upon a quirk that changed recently? That's something.
I think the trick to using the NodeJS/webdev ecosystem is to ignore most of what goes on and to keep one ear barely listening in case something truly useful comes along.
...and update packages with caution. SemVer doesn't always save you and neither will static analysis (because there really isn't any).
Thanks for reading the book and commenting here! Could you please open an issue with the typos https://github.com/amejiarosario/dsa.js-data-structures-algo... or create a pull request with fixes? I'll be more than happy to go over them and fix/merge them. I've spent weeks proofreading the material, but apparently, some slipped through the cracks. Thanks again for taking the time.
Sorry, but since the book itself isn't open source, I'm not going to do your editing for free. There's plenty of paid editor sites out there. If you give me co-author credit and a slice of sales, though...
The book is open-source! All the book's chapters and exercises are open to anybody to see and edit. E.g. First chapter is here: https://github.com/amejiarosario/dsa.js-data-structures-algo.... The offline formats (PDF, ePub, Mobi) are there for convenience (and to solve the limited support Github has for asciidoc's `include` directives) but all the text/code is open.
