To me at this point I question the wisdom of even using URL shorteners.
They almost all get abused by spammers and malware, they end up getting blacklisted, and as a best practice they are generally advocated for end users not to click on them.
In a Corp business environment I haven't found the pains that come with using them worth the shorter URL.
What places are they still widely used outsider of social media?
AFAIK Microsoft use their own URL shortener all over the place including their blog, project, and docs https://aka.ms .
Instead of using random characters, they use a name that clearly shows what it is about for a URL, https://aka.ms/terminal-video as an example. I think it is the best usage of a URL shortener so far.
As a result, we have URL shorteners. They perform the function of <a href="">link text</a>, with the advantage of the users being able to type them by hand, if needs be.
They are immensely useful as an internal tool: if you run one locally, URLs of the form http://link/useful-link-description will quickly become the norm.
I have my doubts that you'll find an increase in url shorteners internally, as one this can be handled through Dns if it must. And how often are people reading and typing urls locally?
For anything like needing to widely distro a URL it will be posted In a commonly accessible page, a email to those needing it, or distribed slide deck.
Or even physically posted QR Codes.
As far as putting them in line in a post, i can see the value there but me personally 250 characters isn't going to make or break my ability to read them.
To each their own though, ans thanks for the insight.
I've worked at several companies that use some form of go links before.
The primary advantage of them is that they are very easily self-serviceable. Anyone can create a new go link, and it's easy enough to do even the HR department managed their own.
You are definitely correct that the same thing can be handled using DNS records and something like a reverse proxy configured to route them based on the subdomain. However, that introduces permissions and ease of use issues. You typically don't want HR to have access to edit DNS records. You can relegate it to a subdomain, but at the point you're typing in "mylink.links.company.com" the shortening effect is dubious. Secondly, managing DNS records is typically technical enough that some groups like HR are not going to want to do it. And if I have to go talk to some group every time I want a go link, I'm just not going to do it.
It's shockingly useful to think "This is a page other people should know about" and be able to enter "go/page-name/edit", paste the link in the box that comes up, and have "go/page-name" go to that page on everyone's computer in the company. Done and done, you made it accessible in less time than it would take to figure out who you have to talk to get a domain name set up.
A secondary benefit is that you can enter a description in your go link. So I can just go to "go/" and get an index of all the golinks we have, with descriptions. It's sometimes useful for when I'm working on a system I haven't used before and want to see what other people have "bookmarked" about it.
>Just seems to me that any company with a remotely competent IT staff could handle this with a few Dns records and a very simple lookup system.
Sure, but that's just an in-house URL shortener :)
> I'm not really seeing how this AD by golinks conveys
It shows that there's enough demand for URL shorteners in the corp world that a company is making a business out of it (even though it's almost trivial to make one yourself).
What problems human-readable URLs solve in the context of URL shortening and modern websites? Their benefit in the past was that on websites with clear hierarchy you could strip URL path or change a word, thus quickly navigating on a site without resorting to clunky menus or site maps, but modern web doesn't look like that, and "human-readable URLs" slightly changed their appearance over the time too.
I find modern auto-generated URLs like, say, news.ycombinator.com/item/21867994-Kutt-a-modern-open-source-URL-shortener to be much inferior: 1. they're longer and much harder to type by hand (and I've seen websites where lowercasing or omission of a single letter past the id results in 404) 2. they don't work well when the author decides to change title (and even HN submission titles change a lot, often multiple times as a result of a long discussion). In fact, (1) is exactly the reason why one would consider using URL shortener today: it's so much easier to dictate and type in by hand!
"Modern" URIs don't have to be unusable. Discourse is a good example of this done right. If HN used discourse style urls, the example you gave above would look like this:
The last form means that when the title changes, the canonical uri can be updated without breaking links to the old location. The only unstable form is the second, without the id.
"What problems human-readable URLs solve in the context of URL shortening and modern websites?"
The problem arises anytime you need to cut and paste, or otherwise transport, a URL between components that aren't directly linked ...
If all you're doing is click-click-clicking like a good end-user, it probably doesn't matter - but if you need the URL for some reason, it can be very difficult - especially in a terminal - to properly move around a 500 character URL.
They are useful for granular tracking (e.g. If you send a link to a resume and you want to make they have read it).
if you have a long URL you want to turn into a QR-Code, using a URL shortener will decrease the complexity of the Code (=improve the readabilty), while allowing you to track how many people scanned it and on top of that you can change which site it is pointing to without redirects or reprints.
We at least use one internally at my big corp. It's nice because instead of routing to some non-vanity URL that looks more like a raw Azure host, we can register x.company.com/whatever to redirect to it. Can only access the links and shortener from inside the firewall.
They're useful when you need to get people (especially large groups) to type in a URL. For example, I use them when teaching classes to e.g. fill out attendance sheets because I can simply write the url on the board.
I'd agree that if the method of delivery is a link, there is no valid reason to use a shortener.
What makes a project "modern"? Seriously curious, as it seems to often be used to describe projects/tools. Is it that the tools and languages used to build it are new? If so, should I care? I suppose if the point is to showcase a useful project in some new language/framework, then I'd care. But otherwise, do I? Like, what if this were built in some really old language and with ancient tools? Feel free to ignore this ramble, just curious what people think.
Not cutting-edge, but definitely not obsolete, and does have obvious benefits over e.g. a traditional plain Python-based app which you need to package and host yourself.
What are the obvious benefits? I don't follow your example... you can run a Python app on AWS, directly on an EC2 instance or in a container, using Lambda, whatever.
I hear ya, but still...I think I feel that you're overstating things. You can use pipenv or poetry or whatever to minimize issues with dependencies, bake into an image and run as a container. I've nothing against typescript or any other techniques/practices you might be alluding to, but choosing those languages/tools based on the kinds of benefits you're pointing to seems rather off to me. It's a bit of work (just a bit) to get deployments working correctly, but once you do, it's there and you can rely on it as part of your infrastructure. I think the decision of which language or framework is going to be used should be informed by something more than the benefits you stated (assuming you meant those are the primary ones) because those seem a bit weak tbh.
A full-scale database server (Neo4j or PostgreSQL), a heavy frontend React app with Redux. A little over-engineered for a URL shortener, I think. That’s a lot of spinning wheels to maintain for a relatively simple service.
But trying to find a brand name that doesn't offend in any language, while also not having to pay $10k to some domain squatter is basically impossible nowadays.
In Hebrew it is the modern noun for "fuck" (as in, the act of coitus) - perhaps you mean that? (And to add insult to injury, you used to "squirt" songs)
Written with a single t, but a word we use to describe poor quality, annoying people, the sensation of hitting one's toe against furniture, that moment when you realize you forgot something important, female reproductive organs (though this is not a very respectful word.) A very versatile word indeed, more the equivalent of the F word I think.
I feel better about this than a commercial service I suppose.
But links should be what they are—the address of a page and not the product of a cloaking and tracking service that takes you to a page with added delay.
I started my project (https://onefiftyone.run) using Mongo. It wasn't intentional, that was simply my stack.
We quite quickly outgrew it, and had to rip out that plumbing for Postgres. It wasn't fun, but in retrospect I realise I was using the new, cool, hip technologies instead of actually evaluating things on their merits.
There's a link in the official Microsoft documentation (for office-js if I remember it right) that uses bitly or a similar service. I don't what happened to that link but now, when clicked, it tries first to load some random porn site and then redirects to a YouTube video (about a car or something like that). I wanted to report it, but didn't find an easy way of doing so, so there must be still there trying to add malware or who knows what to the poor people reading official Microsoft documentation.
I've been through this source code, really clean and well written modern javascript (as far as I can tell). I was completely new to this whole webstack, learned a ton about javascript and building front ends from this. I think an underrated way to get good at coding or even to learn whole new methods is to extend well written open source code. I find myself regularly working with high quality code off github, learning more from the developers on there than the developers I interact with at work.
Hey, creator of Kutt here! Wanted you to know that I'm refactoring client side as well to use TypeScript and new React features like hooks to ditch Redux, and I'm really really excited to push this code into production, so much cleaner now. You check the progress here:
Why do you need to "ditch redux"? Redux is excellent. People aren't "overusing" it as we did previously, but it is still a very good way to manage data and state, and sagas etc are a great way to approach building clients for traditional APIs.
There isn't really anything in pure hooks that can really replace it, performance wise.
If you for some reason really dislike it, mobx-state-tree is probably the best contender to replace it.
It really depends on the use case. For mine, too much time spending on writing boilerplate specially when used with TypeScript. Even mobx-state-tree seems too much for me. I went with something way simpler called "easy-peasy" alongside React Context and I'm very happy with them so far.
They almost all get abused by spammers and malware, they end up getting blacklisted, and as a best practice they are generally advocated for end users not to click on them.
In a Corp business environment I haven't found the pains that come with using them worth the shorter URL.
What places are they still widely used outsider of social media?