I recently moved my blog over from Wordpress to Hugo. I think it must be a lot easier to start out from scratch than to migrate something existing; some parts of Hugo are substantially less than straightforward.
I certainly don't regret the move - much happier having a static site than WP in place - but some of this is much more complex than I had hoped it would be. Amongst other issues;
* error messages can be extremely opaque (although usually easy to google, at least)
* upgrading to new versions is not always straightforward
I deploy my site via rsync, but got bitten immediately by a very odd bug with respect to file timestamps (#6161) where a bunch of my files were warped back to the 1750's.
I personally am happy with hugo. I probably wouldn't recommend it at this point though...
Similar issues from my side. Cryptic documentation, bad dissorganized forum and configuration,... I love the hugo idea but to find one detail you will get into chaos of strange wording and noise. I am using it but I try to configure as small amount as possible as I always get into some undesired behaviour. It seems like it was from begining build with idea and then continued by patch over patch over patch. Cant recomend it either.
I decided I would make a static site the old fashioned way on neocities.org and happily got started. And then I remembered all the double work you have to do linking and making lists and repeating headers/footers (or use frames) and so on. Now I'm back to looking for some simple script that can output static sites without having to spend a month learning a new tool...
It's a mess, and evokes abject horror in some people, but I'll continue to defend the merit of just writing a shell script. I moved it to hugo years ago (ironically) but my old site worked like that: https://github.com/japanoise/website/blob/cdf728d4ebea75cbc9...
It's not pretty to look at, but it can be read, understood, and maintained by one person.
I'm pretty sure my problem with everything I tried so far was that it wasn't me building it so I guess I just have to make some simple script to do it for me some day.
I recently evaluated migrating to Hugo to ditch my hastily written script & use a 'robust, mature' tool. I wanted to add an RSS feed and figured "why work more on my one off script, I could use a pre-built solution!" But migrating was indeed a pain in the butt, and it quickly became clear that writing a function to output an RSS feed was much faster than doing everything I needed to migrate.
Static blogs are very simple, and performance doesn't matter that much for all but the most prolific authors, and you can improve performance if needed. Write your own script!
I'm not sure if I'd call it sound advice - but there's not much stopping you from building a site based around (client side) Javascript these days. Maybe a markdown parser in js, some json (js) data files (à "database") - etc.
If all you need is a blog, it's really just a bit of navigation you need js/<some program> to help with. And you can of course add things like commenting as a SaaS that's essentially just an imported cross side scripting attack on yourself, much like with visitor tracking via Google analytics etc. See for example muut.com for comments.
I tried a few about four years back, when I had much less web dev experience than I do today (not a professional developer). I found Jekyll to be the easiest for me. Just powerful enough to make pretty much any static site I could think of, but easy enough that even I could do it. Hosting was easy too, at the time I just FTPd everything to my provider, but I now o use rsync.
I have a site like that on Tilde Town. It's much smaller than my blogs or other sites, though, so managing links and repeating code is not that big of a deal.
My main issue was how hard it was to do some simple things (or I didn't understand the documentation). I use Lektor for my site and it's been very easy to set up and use, I recommend it.
I like to blog to provide an online presence, but blogging for me is not that important. I cannot justify spending time in configuring and troubleshooting static site generators. I like WordPress because you can get it to work within minutes and all I have to worry about is writing content and coming up with ideas.
I have a self-hosted WP instance, which conducts regular backups, and uses Let's Encrypt and auto renews monthly which I check on every 2 or 3 months to ensure everything is running correctly.
The author seems adamant that blog.domain.com is a worse setup than domain.com/blog - I've seen this argument go back and forth a lot, with both sides claiming advantages and disadvantages.
I am interested to hear the consensus from HN users as to which is better, and why.
From a cloud perspective, it's easier (by a tiny bit of work) to point a subdomain to a service over pointing a folder.
E.g. blog.example.com pointing to a static website while project.example.com points to a server.
If you want both to be under the same domain and use a CDN for only one of them, you still have to configure the pass through of all others... But if it's only one subdomain, CloudFront no longer needs to know about non-Cloudfront endpoints.
I run my Hugo site on S3+CloudFront for a be penny a month (if that), despite also having a $5/month server... It protects my site from going down if one if the 5 WP sites I lazily host for friends gets directly attacked and someone pops a shell + container break out.
It's not a matter of one being objectively better than the other but which suits your needs.
The basic distinction, from a purely SEO perspective, is that blog.domain.com will be treated as its own entity whereas domain.com/blog will be treated as part of the main domain.com entity.
The question you have to ask yourself is whether you want to bolster the "value" of your main domain or if you want your blog to be an asset in its own right.
There is no right or wrong answer — there is simply what's best for your situation.
Objectively better for SEO - and in particular if this isn’t a personal blog, but say a marketing site for your SAAS and then an accompanying blog. Having them in separate domains with very similar content hurts you
This has been fairly well beaten into the ground at this point.
I’d say objectively safer. Google is getting better at reconciling content split across subdomains as coming from a common source. Some Google experts have called it pretty much a solved problem, but I don’t think the data plays that out just yet. I do believe there will soon be a time that subdomain vs subfolder won’t matter for SEO. Just not quite there yet.
As he said, a sub domain is often considered a separate domain when it comes to SEO. His other arguments about naming seems rather hand-wavy, though.
Security-wise, a subdomain can also be a different origin. Which is often positive, so a flaw in your blogging software doesn't allow someone to extract cookies or so from the main site.
Using a subdomain will only protect host-only cookies (those lacking a domain=… parameter). Cookies that specify a domain deal in subdomains rather than origins, so blog.example.com will be able to see any domain=example.com cookies.
This is why using a completely separate domain can be wise if you’re using a third party to host your blog. At Fastmail when we shifted our blog to Ghost(Pro), we moved the blog from blog.fastmail.com to fastmail.blog, so that they definitely can’t get any cookies we may happen to set on domain=fastmail.com (even though our login cookies are domain=www.fastmail.com and thus safe anyway; defence in depth, and all that; by contrast, our product Topicbox does store its cookies on domain=topicbox.com, so the protection of using topicbox.blog is real there).
I feel like x.example.com is preferred over example.com/x because it is simpler to move the files around (when you want the same app/bundle of static files to be y.example.com). Browsers by default will make <a href="/foo/bar.html"> into x.example.com/foo/bar.html when served from x.example.com, but it won't make it into example.com/x/foo/bar.html when served from example.com/x/; something else has to make sure the URLs are correct. The options available to make links work are to generate correct links in the first place (CGI back in the day provided enough information to make this possible, but modern reverse proxies have no way to convey this), never use absolute paths in links (restrictive), or to have some machinery intercept the document, parse the HTML, and rewrite links (super flaky). If you are always going to be at exmaple.com/x/ and never need to change the base URL, you can make it work. If you are making something reusable that people download and self-host, you will pull all your hair out making the /x/ case work well. Therefore, people tend to prefer the subdomain approach. It's just easier, because of an implicit base URL assumed by browsers (and even things like grpc clients). When you try to override defaults, it's like rolling a stone up an infinitely long hill. This is that, I think.
For your blog, it doesn't matter. You can hard-code the entire URL in every link and it will probably never go wrong. Applications are harder. Applications that various people are going to self-host are hardest.
I'm talking about the case where your application is being served at, say, localhost:1234 but the reverse proxy thinks it's example.com/some/sub/path; as far as I know there is no header that says "add /some/sub/path to every URL you generate". (Yes, Host tells you the base is example.com.)
What is the business justification for creating a blog on your website?
In general I would think that it is to create contents and SEO, in which case I believe that it is better to host it under the website's domain. On the other hand you may be targeting a different audience from your main site/product. For example Uber, Netflix at al have "engineering blogs" these days, which clearly have no relation to their product but perhaps rather aimed at being a recruitment tool. In such case you might want to use different domains (which incidentally is what both Uber and Netflix do).
I see people commenting on the technical aspects but the differences are minor and the business goals should be driving the decision.
If you host PHP software like phpBB on a VPS on forum.example.com and have your static website hosted on Netlify under blog.example.com, it's easier to do this with subdomains.
Of course, you can have a load balancer under example.com that acts as a reverse proxy for your forum unter example.com/forum, but the easier setup with different languages/software/servers is to use subdomains imho.
I am frequently setting up new services for try out which are not blogs (e.g.: vpn, online bookmarks manager, chat services, file syncing services, etc.). These require different setting in the reverse proxy and a different subdomain.
blog.domain.com is much better from a security perspective since logged-in session cookies from your main domain won't be sent in blog requests (different origin).
That provides protection for if someone manages to get a malicious script into your blog, they can't start making authenticated requests (since it isn't the same origin).
I keep wanting to use Hugo, and I have made a few attempts.
Moving away from Wordpress and its problems would be good.
I do think a few features are missing that I find valuable:
* Search (you can add it as an external service
I haven't found one I trust and like yet.
* Comments, there are several third-party comment providers
that I can use, I tried out Disqus for a while but I didnt
like nor trust them. I look at using forum software for the
comments but then I have to run that and I might as well stay
in WP
Then there are a few plug-ins I use and like.
The worst part of using WP is of course security.
I have switched to fully managed WP hosting so I dont have to worry too much about that. I do still worry about plugins but my provider does not allow a lot of plug-ins due to issues and I can totally appreciate that.
I'm running my blog (https://muffinman.io) on Jekyll and GitHub pages, and I've run into the same issues.
For search I generate a JSON array, with the name and the url to each post. Then I just client side javascript to search them. It adds a small traffic overhead, but users said they really like the search - it is instant and uses fuzzy matching algorithm.
For comments I use staticman (https://staticman.net/), and it is brilliant. Instead of having a 3rd party comment system, it will issue a pull request to your repo. You can set it to automatically merge PRs or to merge them manually (and moderate them).
The only problem is that because of changes to the GitHub API quotas, their public instance gets overloaded. But you can easily setup your own instance. I use heroku, and their free tier is more than enough for my usecase (I get more than 100k users a year).
I use commento[1] on my site, running on my own server so no third party has access. I do not get many comments though so I don't know how it handles higher load.
Well, as long as Hugo remains a static site generator, it won't be able to support these features "out of the box". E.g. comments are simply not possible just with HTML + JS, so you'll either have to integrate a third-party service (Disqus, Staticman etc.), or move away from the "static site" concept.
There is no lack of technical choices when it comes to starting a blog. I can start five blogs in the next 30 minutes, each one on a different platform/infrastructure.
What I do lack is something interesting to write about, in a consistent manner. I have been writing code for a long time. I did build some interesting stuff. I'm currently working on a startup that does use some blog-worthy tech: any attempt ends up with very long essay-shaped posts, which are extremely time-consuming to write and frankly not so interesting.
Any suggestion on how to find a niche and consistently write about it?
I typically write about things I want to tell people about. Maybe we had an interesting lunchtime conversation, something unusual came up, I'll read about it more and write a post.
Or maybe there's a decision I'm making: I'll write up how I'm thinking about it, where I am so far, and publish that. Often I get good feedback on these posts that makes me think about the problem differently.
I try to notice when I get ideas that would make good posts and write them down. Then, in the evening, I'll sit down, look over the ideas, and see if there's anything I feel like writing about.
I also follow Perell and find him inspiring. Writing is a lifelong passion but since a big part of my work is writing, the flame has gone out. These days is all about relighting the fire.
Start journaling. Just keep a daily log of stuff you do, that you either think is interesting or that you want to reference later. Focus on getting the key points out succintly, writing as you go and then (quickly) editing once you have the problem all worked out. If you do this regularly, you'll get better at producing short and interesting summaries which are great blog topics.
[in my opinion] Don't write to be read. Write for you, write because you enjoy the process and the exposition helps you process and crystallise a concept. Write because you are interested and engaged.
You can definitely do it in a private journal and would likely experience many of the same effects. But putting it online gives other people a chance to learn from it.
Sometimes because publishing helps people stick to doing it. Sometimes because publishing forces someone to a higher standard of care. Sometimes because the mere possibility of feedback or a connection is worth it. :)
My most popular blog post was 'deWiTTERS game loop', which ended up with plenty of links referring to it, including the "game programming patterns" book.
I wrote it because there was nothing else like it.
So if you're researching something, but have to combine various sources and figuring out stuff, because there is no easy blog post, write that easy blog post yourself.
Write about yourself and what you know, its probably the most interesting thing you could write about anyway.
I've been preparing articles for my future blog about my interests and struggles (security, beer, books, mental health). Weird mix but theres no doubt that its more interesting than me trying to force myself to write on one of them consistently
I used to feel such pressure as well because mostly of the current zeigeist that your blog is your platform to market yourself. This adds an enormous pressure for doing quality and interesting post as if you're attempting to publish a paper into a prestigious journal. I'm done with that. These days the main audience for my blog is myself. I like writing and I'm equally prone to write about the coffee I just had and about some clever coding thing.
We all have stories to tell. Treat your blog as a public journal. A place to organize thoughts, share ideas, it doesn't need to be longform in deep stuff. And if you end up doing longform in deep articles, just break them into a series.
What is the purpose of your blog? It heavy depends on this and your target audience.
If you do want to share things that usually end up a long essay, try to make it shorter and easy to understand. It means cut off ideas. Select only general knowledge, so that everyone can understand.
If you follow Medium.com, that’s what happens. Most of popular posts share basic knowledge. And posts with more technical details (some of them are great), often don’t get popular since less people want and understand it.
Also you can start writing random things and share it to learn what interest the audience
I'm no expert, my recently minted blog has one post (book review). I came to the conclusion writing is more of an exercise for myself than a venture to produce content for others. Maybe you should first think about why you feel the need to write and who your writing is for?
I'm not one to give advice, since I don't have a blog of my own. But I'd assume you want to look for an area where (a) you have a natural interest, and (b) for which there aren't a lot of existing resources online.
- What are the implicit assumptions or beliefs? Are those valid?
- What references or sources are frequently cited or quoted? Are those valid?
- What questions, concepts, or sources are studiously ignored or deprecated? Why? Are those valid or invalid?
- What are the dimensions / what is the internal structure of the question? What are its elements, dynamics, and/or relationships? Where do those lead?
- What are the issues encountered in trying to realise solutions, mitigations, or models of the problem? Working in idea-space is one thing, working in instance-space quite another. ("In theory, the same, in practice, different.")
- What new questions emerge? Rinse, wash, repeat.
My problem isn't that I don't have enough to write about, it's that I've far too much I'd like to address, and am looking for a structure and system that fits this.
If you're not at this stage, simply writing, regularly, is good practice. Things you have to say may not seem to be meaningful, and perhaps never will be. More likely though you'll discover a through-thread in the problems and approaches to those problems you're drawn to, though it may take years or decades to discover this.
Writing is a great way of documenting your sources, discoveries, thought process, and evolution of understanding or approaches. It took me several decades before I'd read my past writing without constantly crigning. I still frequently revise or correct older essays (even years old), and HN's very limited edit window is a constant frustration (as are Mastodon and Diaspora's complete lack of re-editability). Your own git-managed blog provides both for editability and a history of those edits.
I've found the process of exploring writing and research methods (tending strongly toward cross-referenced systems: index cards, Zettelkasten, POIC, Wikis) to be fascinating in its own right. Often to the exclusion of writing itself ;-)
Capabilities of a particular platform also matter. If you're writing-as-marketing (a frequent mode), there's one set of tools which may matter, generally fairly well addressed. If you're writing-as-dialectic, exploring ideas or seeking a better understanding of truth, there are others, less-well supported. I find that comprehensive search, thematic organisation (a very good tagging system), and, if feedback is supported (comments, etc.), an exceptionally effective, efficient, and low-cognitive-overhead moderation system matters a lot, as well as the ability to structure posts sufficiently to the needs of expression. A reasonably robust semantic structure (emphasis, lists, sections, tables, figure/images, footnotes, possibly equations) can really matter, and many solutions support this poorly (or require much wrestling).
Content-appropriate themes and styling also matter, with a narrow band between "not enough" and "too much". Again, many solutions support this poorly.
Finally, there's the ability to move your content elsewhere, when (not if) your current platform becomes inadequate or inappropriate, for whatever reason. Something I've come to discover is inevitable.
Another interesting discovery has been writing on microblogging sites. My preference is Mastodon, though Twitter is similar. I'd realised that Mastodon's default 500 character toot length is roughly the same as an index card, which means I can post in threads of roughly index-card-sized chunks. I know this is somewhat annoying for readers, but as a writer, the immediacy of feedback, at roughly paragraph-level granularity, to elements of a longer essay, is invaluable. There's also the notion of publishing in chunks, and committing yourself to a direction publicly, whilst still composing. Several of my longer "tootstorms" really just started as an aside or observation and grew on me.
A key distinction between writing and conversation is that in a conversation, you get immediate feedback. In writing, you commit yourself to a much longer exposition without having a good idea how your audience will respond. (Even speechwriting or presentations are like this, though in delivery you can adapt to audience response.) Microblogging has at least the possibility of bringing writing closer to the conversational mode, which is interesting.
It really depends if you want them connected or not.
In the Hugo example, completely agree. But sometimes it can make sense:
Example.com vs members.example.com vs login.example.com
Example.com can be a static website, while login attempts go to the login domain (which also helps for auth/postback config), and members might be the dynamic content that is viewable once logged in. separates infrastructure in an easy way that has no real impact on SEO
>Note on subdomains: every subdomain, to Google, is a different website. So if your domain is flaviocopes.com, and you create your blog in blog.flaviocopes.com, then that’s a completely new website to Google, and it will have its own ranking separate from the main domain.
So from a SEO perspective it might make sense, if you're running a small blog and traffic is one of your main goals.
These days nobody types an address into the search bar so any TLD that's not country based should be fine. I say that because your home country is a fluid concept.
Anyone looking for a static blog but that wants a decent interface for editing, check out forestry.io. once setup, it commits to GitHub for you, your user is none the wiser. If the service ever goes away, you still have your blog in GitHub. And you can deploy anywhere (s3, netlify, etc). I use this setup for my non technical wife.
I set up a small charity's site I maintain to use GitHub pages and Jekyll. The in-browser editor for markdown is good enough for the non-technical users, and GitHub pages takes care of rebuilding the site. The revision history is handy in case someone does something weird and we need to undo it.
I believe that GitLab pages offers something similar that also supports Hugo, but I opted to use GitHub+Jekyll as I personally find it significantly easier to custom-build a website than with Hugo (I really struggled with on some basic stuff, e.g. I had a lot of blank pages at dir roots (e.g. /something/goes/here would have blank pages at something/ and something/goes/ etc)). Hugo feels over-complicated to me.
Tina CMS [1] is something I bumped into (haven't tried since I'm not enamored by React, or rather, JavaScript based sites for blogs). It provides an editor right on your site, and works with static site generators like Gatsby and NextJS.
Not really in a separate access-restricted area of the site, but I use https://forestry.io/ to update my (netlify-hosted, github-backed) blog when I don't have access to my own machine (or correct a typo from my phone).
Netlify CMS has been impressive for me set and customize.
I just wish these static sites has a smooth way to do image layouts (crop, resize, layout and picset generation). I'd give up MD for that, html+emmet is basically just as simple as markdown.
* edit as for access, I gitlab pages host the static site and leave gitlab to handle the netlify cms auth part.
I've been using Hugo for a few years. I like it generally, but I have mixed feelings about using Go for templating. Compilation and generation is blazing fast, which is great for short edit-compile-debug cycles.
On the other hand, Go's lack of generics makes working with collections harder than it should be... and much of templating involves working with collections.
To give a concrete example, I wanted to create a page where I group categories by post count. Hugo has methods to group pages, but not categories, so I rolled my own imperative grouping code. It wasn't difficult, but it would have been simpler to do declaratively in many other ecosystems (say, .NET with LINQ).
I've been using Pelican¹ with m.css², it does math, sitemaps, RSS feeds, code, graphs and a lot other things very nicely for me. Other blog platforms are far from as powerful, what I've tried, with so little hassle.
(Not OP)Shameless plug: Please take a look at Wemebox CMS https://wemebox.com. I created this because I wanted a dead simple CMS for the websites I create for my clients.I believe it is much simpler than Hugo. Will be open sourcing the source code in a couple of months.
I like the idea of static blogs.
However, I didn't accomplish to find a great workflow to use hugo from my android phone while traveling. Using git on a phone is a pain
I found an app called Teddy Hyde[0] which is designed to make this workflow easier. It's focused around Jekyll but perhaps it's flexible enough for Huge also? Ultimately I couldn't get myself to write anything regularly so I gave up with the whole idea, but the app seemed decent.
Yes this is where I got blocked on this too. I like using the WP Android app to upload photos when travelling. Obviously a static site by its very nature cannot interact with a phone app, so this seems like a difficult/intractable problem.
I have the same use case and have been wondering about solutions too. I'm hosting on Netlify, and when I push to my gitlab repository, Netlify's CI fetches, builds and deploys the site. I've wondered if I can run a script somewhere that periodically checks a private Instagram account (so not my main one), and when it sees a new post, it would download the photo and caption, creates a Markdown post and pushes everything into the git repo.
You could potentially use a regularly scheduled pipeline in GitLab CI to do this. You'd need to use a user token instead of the pipeline token since you want to push back into the repository, but this should be possible. Then, when GitLab CI updates the repo, Netlify CI should jump in.
I've a few sites on Hugo. If you're not an active developer (like me) you can deploy a site from a Netlify template and tweak from there. So pretty much the opposite of "zero to deployment" - gives you something working to start with.
I've been using Hugo for a few years now. Pretty long to set up if you want to addapt one of the available templates to suit your needs, but then it's really great!
I would not advise it to a non-programmer/tech savvy person though.
I run my blog https://www.lewis8s.codes on AWS Amplify. It connects to a GitHub repo and builds it every time there is a commit to master. Uses CloudFront on the backend too.
Costs me around $0.01 per build which isn't bad. Just easier than writing my own script.
Shameless plug: I built https://typehut.com as a simpler alternative to classic blog and publishing systems. It's super easy to get started and it has some nice things like email subscriptions built-in.
Yes, it is, specifically in ease of use of the static site generator itself, especially compared with a Python or Ruby one. (Node things tend to be more amenable to easily reproducible builds.)
From experience, I say that installing Python or Ruby static site generators (Hyde and Jekyll specifically I have in mind) starts out markedly harder, and tends to get steadily harder over time, particularly if you don’t ride the upgrade treadmill¹, whereas the likes of Hugo (Go) and Zola (Rust) are a single binary that you just download and run, and it’ll continue to work forever, and when you switch computers you can just copy or download the binary again and it’ll still work.
This difference concretely saved substantial quantities of time for redoing Fastmail’s website last year in Zola: once it genuinely was just “download Zola 0.8 from such-and-such a location and run `zola serve`”, a few people that would have given up on setting up a Jekyll or Pelican or similar environment, and instead gone with a longer “try modifying it, deploy it and see what happens” or “ask someone else to do it” approach, instead did just download the single binary and use it, because it genuinely did Just Work™.
If it’s hard (here probably meaning “takes longer than five minutes of effort”) to get an editing environment going for your blog or website or whatever, you will abandon your website sooner or later, for a cause that you wouldn’t if you were using one where it was easy.
So I say: prefer a single-binary for your occasionally-updated website, so that it’s your fault when you abandon it, rather than the SSG’s!
___
¹ For example: I used Hyde for the previous iteration of my personal website, and last time I tried to spin up a fresh build environment for it, I genuinely failed—I knew what I was doing, but a couple of packages in there would no longer build. Admittedly Hyde is abandoned and you’re not likely to have quite such trouble on an actively-maintained project, but still: treadmills, and processes that you can’t be confident in.
not really. although hugo is pretty established, too. for a personal blog, i'd just pick one and run with it. getting stuff out is more important than the "right" generator.
(that said, personally, i prefer the runtime hackability of pelican, and i don't find the speed of generation to matter much under 200 posts)
I am currently moving from WordPress to Hugo, so your tutorial arrived just in time. Are your posts part of the content of your ebook series? Just asking in admiration of your frequency of daily new posts.
Great to hear! I'd say the biggest difference with WP is that you don't worry about plugins, updates, server, etc.
Maybe 50% of the posts I write are included in an ebook, I try to write them as a series, so they have a double purpose. One to help if you're searching specific information, the other more organized in an ebook where I explain something from the beginning with a clear structure. Making a series that ends up in an ebook also helps with ideas of what to write about, because I define all the topics beforehand.
The other 50% of the posts are individual pieces, maybe an explanation of a problem or task solved while coding, or just a description of something new I'm learning :)
I certainly don't regret the move - much happier having a static site than WP in place - but some of this is much more complex than I had hoped it would be. Amongst other issues;
* error messages can be extremely opaque (although usually easy to google, at least) * upgrading to new versions is not always straightforward
I deploy my site via rsync, but got bitten immediately by a very odd bug with respect to file timestamps (#6161) where a bunch of my files were warped back to the 1750's.
I personally am happy with hugo. I probably wouldn't recommend it at this point though...