Show HN: Online web tools to get your work done faster(hreftools.com)
hreftools.com
Show HN: Online web tools to get your work done faster
https://hreftools.com
36 comments
I'm curious, who here has a development workflow such that compressing/minifying code via an ad-hoc web tool makes sense? I've always just included it as part of a build process, or at the very least would pipe it into uglifyjs command line. I'm sure everyone's got their own needs but I just don't understand how that would be useful.
You're touching up an old website for your old client and have just a few minutes to...ah, I wonder if there's a quick minimizer out there somewhere? That might be fun to try, and we did just add a bit more overhead to the site.
I haven't done this exact thing, but I've done similar things many times. Not every project has or should have a build process. And unfortunately not all of them even have a command line...
I haven't done this exact thing, but I've done similar things many times. Not every project has or should have a build process. And unfortunately not all of them even have a command line...
If you don't have an established build process, I would consider a one-time minification of an established codebase to be a pretty poor decision.
Either setup a trivial build script, or don't do it at all.
EDIT: Clearly HN disagrees with me. Tell me, what does being a cowboy get you here?
If it's a measurable performance boost, then as soon as you patch it again your site will seem slower. Unless you then manually minifiy again. And again. Until you setup a build script.
If it's not a measurable performance boost, (And I doubt that you know either way because if you're not setting up a trivial build script then I highly doubt you're putting in the time to profile) then what do you get? The next person to come along gets to have a harder time debugging because you don't have source maps?
Either setup a trivial build script, or don't do it at all.
EDIT: Clearly HN disagrees with me. Tell me, what does being a cowboy get you here?
If it's a measurable performance boost, then as soon as you patch it again your site will seem slower. Unless you then manually minifiy again. And again. Until you setup a build script.
If it's not a measurable performance boost, (And I doubt that you know either way because if you're not setting up a trivial build script then I highly doubt you're putting in the time to profile) then what do you get? The next person to come along gets to have a harder time debugging because you don't have source maps?
I agree. Minify once it's released and you can test it quickly once to make sure there's no reference screw-ups, but as part of your development process - don't touch that file. I'd say most web developers follow this process though, I'd be interested to see statistics on minified sources. I'd say at least half of the websites I right-click view-source don't minify.
and stats on how many times these minify and unminify sites have been used would be interesting.
I've used them more than a dozen times. Some sites get the minification just to ramp up a google pagespeed number - not really for the end users - so why bother with a build process? Write some html, ftp. Then pagespeed numbers matter to some people and in some competitive industries - view source, web minify, ftp. done.
I've used them more than a dozen times. Some sites get the minification just to ramp up a google pagespeed number - not really for the end users - so why bother with a build process? Write some html, ftp. Then pagespeed numbers matter to some people and in some competitive industries - view source, web minify, ftp. done.
But again, if it's so important, then why leave it a manual process?
If it's critical to the business needs, script it. If you need to do it every time you fix a bug, make it automatic.
If it's critical to the business needs, script it. If you need to do it every time you fix a bug, make it automatic.
Online tools that minify and touch code always scare me. It would be so easy for them to put stuff in there, like a crypto miner for example.
There's a whole world of developers out their that can't automate anything their IDE doesn't support. For many hitting F5 is their build process: https://blog.codinghorror.com/the-f5-key-is-not-a-build-proc...
I very much love the simple design. Excellent. Please add a favicon generator!
What is the HTML compressor using? It’s missing quite a few opportunities.
Take this input HTML:
Here’s what I say it should have emitted:
Take this input HTML:
<!doctype html>
<html lang="en-au">
<head>
<meta charset="utf-8">
<title>This is a title</title>
</head>
<body class="foo">
<h1>Well.</h1>
<p>I wonder…</p>
</body>
</html>
<!DOCTYPE html><html lang="en-au"><head><meta charset="utf-8"><title>This is a title</title></head><body class="foo"><h1>Well.</h1><p>I wonder…</p></body></html>
Here’s what I say it should have emitted:
<!doctype html><html lang=en-au><meta charset=utf-8><title>This is a title</title><body class=foo><h1>Well.</h1><p>I wonder…
Uh, yeah. Now that we have rules for parsing broken webpages, let's intentionally break our webpages.
If it complies to the spec, it's by definition valid syntax and suitable for production. Now whether or not you want that in your source code is totally up to you.
Just because you can write your whole app in one line of JavaScript doesn't mean you should maintain that as source code. You sure want that as your production bundle though.
Just because you can write your whole app in one line of JavaScript doesn't mean you should maintain that as source code. You sure want that as your production bundle though.
That‘s perfecly valid HTML. Try it. Pass it to a validator.
As I said, we now have rules for broken HTML like that. Yes, it validates. It's Postel's Law run amuck.
The point is that this is legal HTML. The HTML spec does define all kinds of things as illegal (though it defines how the parser should handle them, for reasons of security and consistency), but these things are all legal. All have had the same behaviour forever, though omitting <html>, <head> and <body> tags being legal is, I believe, new to HTML 5. But the rest (e.g. not closing a paragraph tag and not using quotes on simple attribute values) have been legal from the very start, and even popular, though they have fallen out of favour for authoring in recent years.
This is absolutely nothing to do with Postel’s law. I believe that Postel’s law is a terrible idea in most places—it leads to a lack of robustness in practice, and all kinds of security problems, because most programmers are frankly not good at their trade. Rather, the HTML spec defines all behaviour—so there is no liberality about it; you’re simply following the spec with no interpretation—which is the only way to write robust protocols and their implementations.
This is absolutely nothing to do with Postel’s law. I believe that Postel’s law is a terrible idea in most places—it leads to a lack of robustness in practice, and all kinds of security problems, because most programmers are frankly not good at their trade. Rather, the HTML spec defines all behaviour—so there is no liberality about it; you’re simply following the spec with no interpretation—which is the only way to write robust protocols and their implementations.
How is this broken HTML, it's valid HTML
Looks neat! My one critique is the Contact Us link. I find unexpected mailto: links annoying because they cause my desktop mail client (which I don't use) to open unexpectedly when I'm expecting to be taken to a page, in this case a Contact Us page.
Thanks for the feedback. At initial step, I don't focus much on this thing. I will provide a nice contact page in future.
Perfectly reasonable. I would then suggest changing it from "Contact Us" to "[email protected]" to prevent any confusion (Principle of Least Astonishment) :)
Feature request: url encoder/decoder
maybe it's just me but i feel like using of any of these "tools" would slow me down when compared to using the equivalent shell-foo or a language built-in/library.
also seems like a terribly brittle externality to add to my life
also seems like a terribly brittle externality to add to my life
oh man you can't delete comments? another reason why i shouldn't be on hackernews. nice work making something sorry for bein' a jerkk
What is your privacy policy with the data people give you to use your FREE tools?
I'll put a privacy policy page soon. It's just start. Most of the tools I'll put on the website is either browser based or don't rely on any storage. Currently no database system is used on website, so you're safe. Things like compressor (html, css, js) is done directly on memory.
In my bookmarks I have HTML encode/decode and URL encode/decode. Have you considered creating a single input and single output field with different buttons around?
This is great, would love a way of being notified when you add new tools.
add a json validator!
Shameless plug here...
Check out https://jsonchecker.com/
It validates and formats JSON.
Let me know if you have any feedback!
Check out https://jsonchecker.com/
It validates and formats JSON.
Let me know if you have any feedback!
Nice work! Looking forward to see what tools you'll add to the site in the coming future.
Current list of tools: html, css, js compressor, image to base64, json to csv, csv to json, OCR Reader, unzipper (browser only).
Built with react.js (next.js framework) and node.js. Uses some open source packages.
Thanks!
This list may not be representative of “all free online tools” but is sufficient for the context. Perhaps the common thread amongst all of them is that they are served over the interweb. And I wonder what’s the use case?
Edit: typo
This list may not be representative of “all free online tools” but is sufficient for the context. Perhaps the common thread amongst all of them is that they are served over the interweb. And I wonder what’s the use case?
Edit: typo
The use case of OCR is you know, but for compressor like html, css and js is not much due to build tools like webpack or gulp, but it can have. Whenever I want to build a static website quickly or building theme for ghost blogging platform, I search for compressor on the web for quickly testing the compressed output.
Another thing is when I started building this website for my web dev practice, I want to present the simplest tools that can be build quickly. Some of them is the result of that.
Anybody interested in this might be interested in CyberChef [1].
[1] https://gchq.github.io/CyberChef/
[1] https://gchq.github.io/CyberChef/
Awesome site.
It's my go-to Numberwang encoder!
It's my go-to Numberwang encoder!