How to Ship Side Projects - <AUTHOR> http://blog.andyjiang.com/how-to-ship-side-projects/ <comment><USER2> I will agree with the strategy of separating your product into sub-products, and working on and releasing them one at a time. A single, well-executed feature is often better than many mediocre ones.

Especially as a solo founder (shameless plug: I run [https://resend.io](https://resend.io)), I think this is the best way to both test your assumptions early, and to consistently ship improvements without spreading yourself too thin.

I've taken this approach as I set out to compete with companies with 100s of millions in funding and 100s of employees who had built out very feature rich and elaborate product platforms.

In my specific case, it went something like

1\. build a shitty live chat plugin

2\. make said shitty live chat plugin good

3\. extend previously shitty live chat plugin with shitty automated messaging capabilities

4\. make those shitty automated messaging capabilities good

5\. and so on..

In between each step you should try and get people to use it, be shameless. You'll often be surprised that you can find users already at step 1, despite competitors already rocking well-established and mature solutions.

Doing this long enough (I have been going hard for 9 months), all of a sudden you'll find yourself with your own platform, built slowly by stacking one brick on top of another, and sticking to it.

<comment><USER3> Or just shamelessly ripping off intercom's product is another quick way to iterate and test your assumptions.

<comment><USER2> If you can execute well and if the demand is there, that's definitely a viable strategy to get you off the ground - Ride the wave

<comment><USER4> The product looks really good. Is the design yours as well?

<comment><USER2> I wish, more like some weird amalgamation of other websites blended together with my caffeine trips and sleep deprivation. I once heard good artists borrow, great artists steal

</comment></comment></comment></comment></comment><comment><USER5> My trick has always been to solve one of my own problems, and be my own first customer. Then I know it works, and meets the goals of the audience. I figure that if I need the problem solved, so do other people, but even if nobody else ever shows up, I got my own value from it.

<comment><USER6> The problem is polish, documentation, marketing, promotion.

There's plenty of stuff that i've made that's useful in the form of an inelegant API that i don't mind using. But to build a polished product with documentation, a marketable presentation, analyze what you offer that the competition does not, getting people interested, blogging about it, is quite a lot more perspiration.

Writing a useful MVP is necessary, but often the easiest part. Most ideas dont fall under "if you build it and they will come".

<comment><USER7> Totally agree. Building a usable, shippable, commercial grade product and actually getting people to pay you money for it is quite an ordeal. An enormous amount of attention needs to be paid to get a product nobody cares about installed, even for free. Even after the sale, you have to provide support which will run at a loss until you reach a customer threshold.

The SaaS and subscription model evens out the revenue spikes, but you still have to make the sales.

A salesman, I am not. I suppose I should learn how to do it, but I don't have much passion for the sales side of business.

<comment><USER6> This is usually why you need 2 people. Someone to build the product and someone to sell the product. There'd be no Jobs without Woz and vice versa. Exceptions to this are unicorns. It's not surprising that the presence or absence of co-founders is a strong signal to investors.

<comment> ezequiel-garzon I thought the only down-to-earth meaning of unicorn was a startup with a $1B+ valuation, regardless of the number of co-founders, no? [1] Your statement "There'd be no Jobs without Woz and vice versa. Exceptions to this are unicorns." seems to indicate a restriction to one founder for unicorns.

[1] [https://en.wikipedia.org/wiki/Unicorn_(finance)](https://en.wikipedia.org/wiki/Unicorn_\(finance\))

<comment><USER8> There can be multiple species of unicorn.

</comment></comment></comment></comment></comment></comment><comment><USER9> Shameless plug, I just launched an overhaul to a side project today ([https://instacalc.com](https://instacalc.com)).

The biggest impetus was having a friend using the old version who pinged me with some feature requests. It reminded me that the service can help people I know directly and gave me a huge boost of motivation. If friends and family are using it, you'll want to help them out :).

<comment><USER10> Doesn't seem to work on Safari (9.1.3 on macOS).

<comment><USER9> Found and fixed the bug, should be working now. (For what it's worth, I was using fat arrow functions in javascript, which aren't supported in all browsers yet. Forgot to compile it down to ES2015.)

</comment></comment></comment><comment><USER11> Limiting the scope can't be emphasized enough if you're married with kids.

I've failed to ship 6-7 side projects because of limits to my free time. The best side project I've successfully shipped, besides blogging, was limited to 2 "features" one of which I already had from a failed project.

<comment><USER12> So basically, try to group anything into smallest possible self-contained utilities, until you grow a pile of them big enough that your next project can be basically assembled from them...

<comment><USER13> Ironically, my current side project evolved exactly the opposite way: I tacked on more and more features, and later broke everything apart into plugins once the correct abstraction had emerged.

</comment></comment></comment><comment><USER14> I used to be the kind of guy who started a lot of things, but never finished them. I got angry at myself, and built a project with the sole goal of finishing it. The challenge of "just get it done" really put me in the right mindset. Since then I've started finishing what I started. Here's some tips.

If you're going to try a new to you tech, only use 1 new to you thing at a time. There is nothing wrong with using a technology that's old. In fact, that's the best way to finish something. Old technology is googleable, stable, and usually has libraries for everything you want to do. New tech might let you do in 3 lines what old tech will do in 20… but getting those 3 lines of code to work might take more time than just writing the extra code. The next point, elegance does not matter. NO ONE cares about your project. They aren't going to review the code, so why spend time doing something elegantly? Just get it done.

As mentioned in the article, you really have to realize your limits. At work, when you have a large team, the definition of MVP can expand. When it's just you, you REALLY need to think about what value you're building. I'm constantly asking myself "is this thing I'm going to spend today on actually going to be the difference between my product being useful and not working at all". "Is there a way I can get away with faking, or doing this thing manually". If you only have a few users, you might not need to automate right away.

One more personal preference, I don't talk about what I'm working on with friends and family until I'm near done or done. For a few reasons, first if you talk to other engineers, they'll discourage you. When you propose an idea to another engineer, they're shoot it down pointing out minor flaws. I used to think, oh that's useful… they're preventing me from going in the wrong direction. Upon reflection though, I'm not sure the advice I've gotten has always been "useful", it has made me give up on ideas. Maybe I'm weak willed, but this is what I need to see my ideas get done. If you really believe what you're building will work, the only person worth talking to are your future customers, if your future customer isn't interested… that's actually worth something.

</comment><comment><USER15> This was a good blog post. I have shipped side projects before. What helps me the most is to always have some really, really tiny incremental goal every week that's achievable. This way, there's always some momentum of sorts, even if some weeks are far less productive than others. It's when momentum dies completely that projects don't come out of the abyss.

<comment><USER16> I have found the same. Stressing to make massive progress or sneak in a 6 hour session makes me burn out super quickly, and the inertia of starting a bigger feature makes it less likely that it will happen.

I have shipped a few web projects this way and found it's been just as useful for game development. In the rush to see progress I burnt out learning last time, but this time I am making serious progress with just a small task each day or every couple of days.

Also adding minor bugs that are turning into rabbit holes to a backlog for later helps keep me motivated.

</comment></comment><comment><USER17> I find aggressive scope-cutting to be one of the most compelling things about building side projects.

I'm shopping for computer parts at the minute so built a quick app to scan UK shop deals, threw it up at a subdomain of my personal site (plug: [http://slackfriday.jhope.ie](http://slackfriday.jhope.ie)) and let it go. Over cyber monday and later it got loads of traffic and watching a stupidly simple app do it's job was thrilling and liberating.

Even doing agile and lean MVPs every day at work nothing quite matches the level of focus you can reach when you know your own capacity and have a time- limit. I kind of disagree with the OP in that even if you use tech that you're familiar with and have a fleeting idea it's still worth doing every once in a while to remind yourself why and how people use things.

<comment><USER18> how did it get loads of traffic, from where?

</comment></comment><comment><USER19> To add another shameless plug, I built a search engine for lectures ([https://www.findlectures.com](https://www.findlectures.com)).

A great thing about this is that there is no point where it's "done", as long as it has enough content to be useful. As I get more data, it unlocks tons of opportunities for mini-projects. Writing a blog has been a good side-project for the same reason.

<comment><USER20> That's pretty cool. I would love to see the JVMLS or JavaOne videos to be listed there.

J1: [https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g](https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g)

JVMLS [https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI...](https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_)

<comment><USER19> Thanks! I'll add these to the list.

</comment></comment></comment><comment><USER21> I wanted to read this post but I couldn't get past the light grey font which was very hard to read. Illegibly thin and light fonts like this are borderline hostile to users, and frustrate me every time I encounter them.

I'm sorry I have nothing more constructive than that to contribute.

</comment><comment><USER22> I really like the idea of approaching rapid development like writing an essay or a blog the first time. Just getting all the words out on the paper goes a long way; same thing goes for programming.

<comment><USER23> I understand your mindset, but sometimes a little bit of planning upfront can save so much time in refactoring. I'm not sure code is analogous to writing save for maybe a choose your own ending type novel. An Essay is essentially a sequential flow of ideas where as a program is more like a tree. Perhaps what you are referring to is rapidly developing the nodes(classes) of that tree without concerning yourself to much with the connective branches between classes. If that's the case then I can see the benefit.

<comment><USER24> From purely technical viewpoint that is correct and engineer in me agrees with you 100%. However: if you look at the bigger picture you will notice that the feature list is not known in advance. Which means the nice abstraction you made are probably unsuitable and will make repurposing software _more_ difficult, not less. Because nobody knows what the end product will look like, so it pays to ship fast, iterate on product design and refactor / rewrite later.

But I know what you are saying, I have struggles with that inner engineer daily and he just won't shut up. :)

</comment></comment></comment><comment><USER25> I am working on a side project called Metriculator ([https://www.metriculator.com](https://www.metriculator.com)).

This is my personal experiment to see if I can build and market a full-fledged SaaS tool. It has also been a nice way to pick up a new programming language (Elixir).

I have a lot of unfinished projects. I start working on a new idea, build out some functionality and then the interest fizzles outs and the project is left unfinished.

This time, I decided to take a different approach - I decided to keep publishing the app incrementally. I started off with just a landing page first, last week I added the demo survey. There are a LOT of things left to be done before I can roll out public access to this project, but getting a few beta users has been a nice inspiration to keep me going.

</comment><comment><USER26> I've really enjoyed this comment thread because I started feeling like everyone was shipping their side projects but me. Turns out I was only seeing the highlight reel. Weirdly, the fact that everyone seems to have problems with this, encourages me to keep trying to work on it.

</comment><comment><USER27> I agree "Ship it" part. My previous side projects is always by this styles: "good idea" (1 week) => develop it (2 week) => "not satisfaction" (several days) => abandon => next idea .... The passion always dispears after one month, so in one month, need ship it. BTW, the Show HN is really really good channel for every early shipping.

</comment><comment><USER28> Scope creep is the enemy. I'm a big fan of the minimum viable product idea. What is the smallest thing you can build that lets you quickly make it around the build/measure/learn loop.

</comment><comment><USER29> One big issue with working on side projects is that you get emotionally attached to it and sometimes it takes over your mind, more than it should. Learning to balance that would help you be at peace at slow speed of the side project, after all it's called side project for a reason.

<comment><USER30> How you manage in that case?

</comment></comment><comment><USER31> As a designer this become even more problematic.

I have been depending on developers to do the hardcore development (I can do web-coding myself well enough) and are therefore depending on convincing developers to help me.

After a number of attempts at starting various products/services with various levels of success but ultimately fizzling out.

Ex. Weekendhacker have around 8K designers and developers subscribed but it kind of died out, because the time i spent vs. any income I made was not making sense. I haven't killed it but it's basically in hibernation until I figure out what to do with it. It was a really frustrating to see something like that die out with such high hopes of starting an actually community.

However I finally managed to launch something that is generating growing side income for me year over year, which I can control the progress of and which allow me to expand slowly but surely.

[https://www.ghostnoteapp.com](https://www.ghostnoteapp.com)

Now GhostNote is only the start of something much bigger I am building but it allow me to control the scope and slowly expand what I am doing while still enjoying it as an added bonus I am making good money.

You should ask yourself the questions like.

Why am I building what I am building?

Is there a simpler way to do what I want to do. (Ex. could it just be email to start with? Weekendhacker was.)

Is this really what I want to spend my time on?

Does the world really need this?

But most importantly you should never give up, sooner or later you you wil find something as long as you make sure you don't spend too much time on each.

I have literally hundreds of ideas, a whole graveyard of almost implemented projects

Just keep trying new stuff, make new alliances with developers. Do several things at once if you have to. But if you want to make money with your side project don't be too attached.

</comment><comment><USER32> Start with a credit card form.

If nobody would pay for it, why would you invest precious time building it? You have better things to do. :)

<comment><USER33> And if everyone followed this advice, we'd have no Kahn Academy, no Wikipedia, no Linux and a much poorer world.

<comment><USER32> None of those are side projects. There's a time and place for change the world free stuff and a busy person's free time is rarely it.

<comment><USER34> Khan Academy history ([https://en.wikipedia.org/wiki/Khan_Academy](https://en.wikipedia.org/wiki/Khan_Academy)): The organization started in 2004 when Sal Khan tutored one of his cousins on the Internet using a service called Yahoo Doodle Images. After a while, Khan's other cousins began to use his tutoring service. Because of the demand, Khan decided to make his videos watchable on the Internet, so he published his content on YouTube.[9] ...The critical acclaim and the positive responses of students prompted Khan to quit his job... and focus on the tutorials

</comment></comment></comment></comment><comment><USER35> Aggresive scope cutting while maintaining the usefulness of the app is tricky but will payoff for that elusive launch day

</comment><comment><USER36> The biggest problem I've had with side projects in my past jobs was that my employment agreement was all encompassing and I would require my employer's explicit permission to release the project. So I pretty much stayed away from them except as purely throwaway learning exercises.

</comment><comment><USER37> i think reid hoffman's quote (linkedin founder) sums it up best, "if you're not embarrassed with the first version of your product then you've launched too late."

i have seen many posts about mvp and narrowing scope here--all right on the money.

some other things that have worked for me, i'm the world's biggest procrastinator and i have literally 20-30 side projects that i've started for some time, was extremely passionate about, and then moved onto the next big thing, but i've recently had a few projects that i went deep on and actually got out, even hoping to build a business out of.

i've also found that the technology stack is not that critical, as a perfectionist i want to create a kickass platform that's easily maintainable, beautifully coded, using all the right tools that can meet billions of requests per day from the start, easy to deploy, automated, etc, but that typically just leads me down a huge rat hole. if your energy is finite (for me it is), you should focus all of it on getting your stuff out the door as quickly as possible, getting it in front of potential users because often times what you think is a great idea is raw and will need tuning. make things functional, able to showcase your main idea (or a particular use case), don't have to have all use cases fully done. get it out there and iterate. i'm certain that there are people that can make all the right technology decisions from the get go to support billions of requests per day, fully automated (if you are one of these, please email me right away!) but you're solving the wrong problems, if you want to get a side project or business out there, go build it, get it out there and then iterate, and iterate fast.

for the sake of argument, probably side projects like tools or libraries, these are a bit different in nature, you probably want to choose the right technology stack, etc. but if you want to build a business out of your side project, then don't dwell on this too much, use what you're familiar with that can give you the quickest turnaround, there will be pains with whichever tech stack you choose, some more than others, but it will pale in comparison to the roadblocks in front of you to build something into a business.

for one of my recent projects, i use sqlite3 for my relational database, i don't even want to spend all the 30 minutes or whatever to set up postgresql, it's to that level of scope reduction. when users grow, then i'll spend the time to upgrade and add backups, etc.

<comment><USER10> But what's an MVP? That's very subjective.

I'm working on a DITA (to PDF) renderer [1] based on rinohtype [2]. About a year ago I was in a startup coaching project. I was advised to put out an MVP ASAP. Since then, I've worked full-time on the project and only now I'm releasing what I believe is an MVP. One year ago, my product was functional, but it didn't allow easily styling the output PDF. I believe this is the feature that differentiates it with the competition. I feel that, without this feature in place, my product wouldn't offer anything interesing.

I could have also released an "MVP" much earlier, but say it couldn't render tables. Who would've taken it seriously then? Even if I added this feature at a later point, how many of the people that tried the first version would bother checking it out again?

For some (new) markets, I'm sure you could crank out an MVP in a month. But for existing markets, there's the established competition that sets the bar, no?

[1] [http://www.opqode.com/rinoh](http://www.opqode.com/rinoh) [2] [http://www.mos6581.org/rinohtype/](http://www.mos6581.org/rinohtype/)

<comment><USER37> no doubt, you raise an excellent point--mvp is somewhat vague, hard to quantify, and there's no universal answer so unfortunately the answer is it depends on the idea/product/lifecycle. chances are if you're still trying to get a feel for a market, this could be an entirely new market, one that doesn't quite exist, or an existing one with incumbents, like airbnb as an example, an mvp could be like a simple mobile app with login (not even oauth based for facebook/twitter/google), listings, a way to book, and bill. don't implement user feedback on listings where they've stayed, don't implement icons for users, forgotten password is an email to support, etc, i'm sure you could find a million things that are needed, but what are the essentials for getting people to use your app satisfying some specific needs (crashing at a complete stranger's place). each feature doesn't really need all the bells and whistles, enough to get people to start using the basics. your assumptions and hypotheses about how the market would leverage this tool could be entirely off, so you might need to change direction (pivot more or less) and you'd need to get to this conclusion asap, sooner rather than later, etc. if you spent a year coding something you think would be perfect for a market you are defining or discovering, this could be a large waste of time, so fail fast as they say.

in your case, you seem to be quite clear about what you need, what the competitors have and don't have. but let me play devil's advocate because i don't know how much effort "[rendering] tables" would take or how much you've put in the past year, but let's just say you could put something out there in 6 months time as opposed to 12 months time, it probably will have some table rendering, not 100%, but do you think that would be advantageous or not?

thanks for the footnotes, much appreciated and good luck with your app!

</comment></comment></comment><comment><USER38> I wrote this a while back which touches on some similar points: [https://jimter.net/open-source-the-journey-from-project- to-p...](https://jimter.net/open-source-the-journey-from-project-to-product/)

</comment><comment><USER39> This is smart. Start by developing the smallest and most essential solution to a problem, get feedback, and incrementally improve the solution.

</comment><comment><USER18> I like it, except for the part about "refactor later" in my mind the best way is refactor "first" so that adding your feature is "easy"...though I don't always follow my own advice with hobby projects LOL. Don't let technical debt subsume you, though, fight back eventually.

<comment><USER18> I do like the part about focusing on "the next feature for your customer" though, customer centric can take you far, that's good...most/many hobby projects focus on only the next "feature for me" and never get around the marketing/polishing side of things, whereas focusing on customer-ish stuff encourages the latter, the latter being 80% of success typically overall (or get a partner to do that part, the common successful way there...)

</comment></comment><comment><USER40> I just want to say it is OK to give up from time to time. I had a serious side project I worked on for 2 years. Sometimes you need to cut your losses. I was able to use a product that cost me $100, though it doesn't work exactly as I want, it does the job. So just ask yourself, is this worth it?

</comment><comment><USER41> If you need some additional motivation, I recommend Just F*cking Ship ([https://unicornfree.com/just-fucking-ship/](https://unicornfree.com/just- fucking-ship/)). It helped me get out of a rut and focus on what's most important.

</comment><comment><USER42> I'm going to go ahead and disagree.

I suggest that instead of this approach, you take an _approach_ of starting by overengineering it and making it absolutely perfect in every way - then just ship the part of that you manage to actually do.

Sometimes the best way to write a short story is to write a three-volume epic.

<comment><USER43> I think I'd need to see some evidence that that is a more effective strategy than starting small.

My biggest enemy is always analysis paralysis. The bigger the project, the less likely I am to ever even start, much less finish anything. Likewise, when I do start, if the scope is too big, I'll flit from concept to concept never really finishing any of them. But, when I have a very small, concrete, and actionable item, I can knock it out in no time...it almost doesn't even feel like work sometimes.

I don't think the "overengineer it" approach could ever work for me.

<comment><USER42> >I think I'd need to see some evidence that that is a more effective strategy than starting small.

"To begin with, GNU will be a kernel plus all the utilities needed to write and run C programs: editor, shell, C compiler, linker, assembler, and a few other things. After this we will add a text formatter, a YACC, an Empire game, a spreadsheet, and hundreds of other things. We hope to supply, eventually, everything useful that normally comes with a Unix system, and anything else useful, including on-line and hardcopy documentation."

Looks like he did all that. (Mostly in the form of Emacs). Anyway it's hard to get more ambitious than a list like that. Other early announcements of effective projects were the same - very large vision.

<comment><USER43> Counter-argument: GNU was a copy of an existing reasonably well-engineered and well-documented solution, in almost every piece. Sure, GNU utilities often improved or extended the standard, but the design already existed. Further, GNU is a system of many discrete parts. Each piece could be built by an individual without tight interdependence on other pieces. That's an MVP. Small, useful, pieces, that add up to something bigger.

I believe GNU is evidence of the opposite point you're trying to make. Unless your point is actually "think big, but build in small, manageable pieces", but if that's your argument, that wasn't how I understood it.

Ambition is not antithetical to building in small pieces. In fact, I think most people have to start small.

While we're on the subject, I'll quote another kinda famous first announcement:

 _Hello everybody out there using minix –

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)_

<comment><USER42> >Unless your point is actually "think big, but build in small, manageable pieces", but if that's your argument, that wasn't how I understood it.

Unfortunately, that was exactly my point!

I've made a modification to my original comment: I've italicized the word "approach" now, to emphasize that this is just the kind of _attitude_ you should have.

Basically, my main point is that if you don't overengineer a perfect and very ambitious solution, you're unlikely to ship anything - but if you do, then you are more likely to ship it, even though obviously you will start shipping some small part only.

It would be interesting if there were some way to do a double-blind experiment, giving a thousand people a couple of different approaches and to see who ends up shipping :).

in short, I'm saying, by targeting something _huge_ and overengineered, you are more likely to ship _something_ (anything at all) - versus targeting a minimum; which leaves you less likely to ship anything worthwhile. I am not saying by targeting something huge and overengineered, you are going to ship something huge and overengineered. Rather, that you will end up shipping a small part of it. (And that this approach is better than the alternative.)

</comment></comment></comment></comment></comment><comment><USER44> Maybe the "tenth callback" is just a bad example, but I would emphasize not doing anything that will sap your motivation on the path to shipping. For me, that's having to deal with brittle code when I'm constantly reevaluating the requirements.

</comment><comment><USER45> I really enjoyed reading this. I have been stalling on a side project for some time and this article has given me some ideas with how to proceed. Specifically narrowing down the requirements.

</comment><comment><USER46> Sorry but those animated gifs distracted me from reading. Normally I will scroll things like that off the page but when they come so close to each other all I see is the movement.

<comment><USER47> We're now coming full circle [1]... Chrome's inspect element followed by the Delete key works wonders though.

[1] [http://www.wonder-tonic.com/geocitiesizer/](http://www.wonder- tonic.com/geocitiesizer/)

<comment><USER48> There's a chrome extension I find very useful that adds this to the right click menu called "f*ck overlays" [1]

[1] [https://chrome.google.com/webstore/detail/fck- overlays/ppedo...](https://chrome.google.com/webstore/detail/fck- overlays/ppedokobpbdajgiejhnjfbdjlgobcpkp)</comment></comment></comment>


Ask HN: Help, we need (real) NYC office space. - <AUTHOR>

We've grown from our apartments, to working within consulting client offices, to a small WeWork office (executive suites), to the open loft in Projective SoHo (co-working). All of these options have the same major drawback: distractions.
At home, the distraction is being separated from each other. In other spaces, the distraction is another company's non-hackers doing whatever it is they do (loudly). The recent HN link to "open floor plans must die" is spot on.
We'd love to follow Joel's old advice (http://www.joelonsoftware.com/articles/OfficeNewYork.html), but we don't have the time to find and build out an office from its skeleton. We're hacking towards deadlines.
After conversations with brokers and small biz owners, it's obvious the commercial real estate game is just as broken, if not more, than the residential one. I think in an ideal world, we'd just rent a residential loft and hope no one minded half a dozen folks hacking there instead of sleeping.
Have you gone through this? Do you have any ideas or leads? <comment><USER2> Do you need to be in Manhattan? There's some smaller offices still available in DUMBO (but going quickly). Downtown Brooklyn has a lot of vacant Class B type space. Slightly off the beaten track is some just renovated space on Front Street in Vinegar Hill (a couple of blocks north on Front Street from DUMBO proper). 231 Front I think, mix of pure rentals and co-working spaces.

If you want to stay in Manhattan (or must), consider looking in the old garment district, W30s between 7th and 9th avenues. Still a lot of loft style space that you can carve up whatever way you want.

I haven't looked for office space recently, but if I had to I'd probably start first by finding a decent broker. NY real estate is still very old school "I know a guy" type of networking & negotiations.

Also consider asking for referrals to people/places on either the nytm list or nextny.

</comment><comment><USER3> I see this mentioned a lot - what is broken in the commercial real estate game?

Looking at one of the REITs I own shares in, they claim a commercial vacancy rate of 14% which isn't going to give a lot of room for negotiation.

But if you're looking for a loft/open space, you can fill it with partitions that you can buy or rent. It isn't a perfect office, but, easy to construct with minimal delay in getting to the new space.

<comment><USER2> What's broken is that many NYC commercial/office rentals won't offer a flat "this is how much we charge PSF", instead it's "well, who are you, what are you doing, and what's your budget?"

<comment><USER3> It's called qualifying your prospect. I suspect something you said or did suggested that you were going to be a lot of time for a minimal commission and they didn't want to be bothered with it. Short term and small leases are very uninteresting to brokers as their commission is based on the total lease value.

1) Who are you? Are you going to be around for the long haul, is it temporary, are you likely to be able to pay the bills or are you going to break the lease in six months when the desire arises. When you break the lease, are they going to be able to collect the termination fee, if not, that all gets factored into the price.

2) What are you doing? Is it a data center, are you going to have a lot of foot traffic, are you going to have people living there all the time writing code, requiring them to keep the environmental units on all the time, i.e. do you need to be in a 24x7 office building. In DC and Baltimore where I leased a lot of space over the years, many buildings didn't operate chillers on the weekends and a southern exposure with untinted windows made it unbearable. Even during the week, the A/C units struggled to keep our space cool, but, it was cheap - and now we knew why the law firm didn't have a problem giving up what we considered 'prime space'.

3) What's your budget - do you want scenic views of the Hudson or Central Park, or, are you willing to get space somewhere without a view. Real estate gets more expensive the closer you get to public transportation in NYC and a few other cities. Windows add to it. If you're looking for a space just to get people together on a daily basis and can turn a cave into a workspace, then you can find properties that have been carved out of companies that have downsized where they kept the window, but threw away the rest of the 'useless' space. However, if you want that window view from the 50th floor, it isn't going to be cheap. Most floorplans in cities try to make sure every office has access to the central core (elevator bank) and windows. Space without windows is typically storage. One of the spaces I rented in Baltimore was a 1440 sq ft chunk out of the back of a surveying firm. No windows, crazy hallway cut from their office that wound back to the space, but, again, space they were willing to get rid of and remove from their lease. I did sublease space in DC one time in a building and we brought our own construction crew in, created our own door in the hallway and took a chunk of their space.

Find a broker, tell them that you want x thousand square feet, you want a one year lease with two one year options, you don't need a buildout, you're willing to settle with property without a view and you're willing to do a quick close. Be careful with the lease terms and make sure they specify whether it is net or triple net so you're not surprised with the property tax being added to your rental with the first bill is due.

Every building is different, most have separate owners even if they share the same management company. Almost all properties count common space as shared among the lessees based on a percentage of the square footage you lease. Even different floors in the same building can have different prices. Make sure they tell you what the final price is, in writing, on your lease agreement before you take it to your attorney. Depending on whether they have a concierge or doorman, the level of security in the building, i.e. security guard, access control all contributes to your lease price.

Double check utility cost, high tech companies are sometimes asked to submeter, additional cooling requirements are often factored in. You can ask for a space with a shower, but, absolutely don't tell them people are going to be sleeping there. If they ask, many of the employees ride bikes/rollerblade/etc. Find out if you are required to use their cleaning service (or if it is included).</comment></comment></comment>


The 100 oldest .com domains on the internet - <AUTHOR> http://theforrester.wordpress.com/2007/08/13/the-100-oldest-domains-on-the-internet/ <comment><USER2> Interesting if you haven't seen it before, but that blog post is kind of terrible. (Calling them "WWW" domains? In 1985?)

Wikipedia has the list too, along with the corresponding domains in .org, .net, etc.:

[https://en.wikipedia.org/wiki/List_of_the_oldest_currently_r...](https://en.wikipedia.org/wiki/List_of_the_oldest_currently_registered_Internet_domain_names)

<comment><USER3> With the dominance of the WWW now, most people don't realize the Internet (and the ".com" nomenclature) predates the WWW.

</comment></comment><comment><USER4> I worked at BBN (#2) for 2.5 Years right when I graduated from college. Genius level colleagues; The types of guys that would download computer viruses and decompile them "Just to look at the code."

A funny story is when they called me for an interview, my Mom said "It's BB&T on the line." and my response was "I bank with Bank Of America." Then she said "Just take the call!"

<comment><USER5> Not to be confused with BB&N, the private school just down the street from it...

<comment><USER6> That did confuse me for years. I thought there were a bunch of child prodigies working for BBN.

</comment></comment></comment><comment><USER7> This list makes the rounds every year or so, but I always like seeing it; one of the domains is a special one to me, although I was not there at the time it was registered. UniPress Software (unipress.com, #80 on the list) was my first job while in college in the late 90s, and gave me the ~14 year experience of creating a product that went through all of the stages from "figuring out if people want a web-based application that does ___" to being a grown up, enterprise software that was acquired by a very large company. The two founders had real software-startup instinct before startup/entrepreneur was something written about, a love for what it is that we do, and are still close friends. It was a great place to be, a great time, and awesome people to be around. The two founders reached the age of retirement and sold the company years ago, but have been involved in two startups since, just because it's what they like. It makes sense that they would have bought a domain when it was a "pioneer" thing to do.

Most recently, seeing that Twitter was becoming very popular, Mark had been pumping out PHP code using CodeIgniter and made www.mediaroost.com in his spare time, a Twitter Management platform. It didn't take off, he retired it, but had a good time. Going way back, this is the same guy who wrote C compilers and sold Whitesmiths Ltd which released the first commercial C compiler.

(and going back before my time again, but interesting history - UniPress had also purchased Gosling Emacs which then became UniPress Emacs, controversially asking Richard Stallman to stop distributing GNU emacs source code.)

<comment><USER8> YOU EVIL SOFTWARE HOARDER!!!!

Ha ha, just joking. ;) I worked for UniPress too, on Emacs. There was a certain professional animosity between Stallman and UniPress. Stallman had a justifiable axe to grind against UniPress, which he expressed by calling UniPress "Evil Software Hoarders".

But between the individual people, it was more like the relationship between the cartoon sheepdog and the coyote, that was friendly and respectful after everyone had punched out of work.

Just after RMS's house had burned down, Mike "Emacs Hacker Boss" and I were wandering around a science fiction convention and ran into RMS (who is a fixture in the east coast SF con scene). Mike sincerely asked him, "Richard, I heard a terrible rumor that your house had burnt down. Is that true?" To which RMS replied without missing a beat, "Yes, but where you work, you must have heard about it in advance."

We all had a great laugh from that -- RMS is a very funny guy who's quick on his feet, with a sharp sense of humor! Just don't let him get under your skin, like when you post a baby announcement to a mailing list for arranging dinner get-togethers on the other side of the country than he lives: [http://www.art.net/~hopkins/Don/text/rms-vs- doctor.html](http://www.art.net/~hopkins/Don/text/rms-vs-doctor.html)

Here's an old picture of JSOL, RMS, Liz and Mike, where RMS is holding a gerbil wrapped in duct tape, about to ask, "I don't know, why do you wrap gerbils in duct tape?" (Now you can ask google if you really want to know...) [http://www.art.net/~hopkins/Don/images/jsol-rms-gerbil- liz-m...](http://www.art.net/~hopkins/Don/images/jsol-rms-gerbil-liz-mg.jpg)

</comment></comment><comment><USER9> Sat with a fellow student at 3am in a UMIST lab in early 90s. Trying to resolve 'levi.com', 'cocacola.com' etc. on some early rev Mosaic ... rarely find a registered brand ... "someone needs to make page with a list of ones that work" ... go back to COBOL project.

</comment><comment><USER10> There was no web in 1985.

But there was an Internet. Companies registered domains for email addresses, FTP servers, etc.

</comment><comment><USER11> There's gotta be a way to create a site where you can catch up on stuff that is often resubmitted to reddit and HN (and even digg!). I don't know how one can do that without human moderators or expensive and difficult AI.

People who have never seen this list before find it interesting. People who have been on reddit and HN see it every other month. Some way to please both groups so everyone is happy would be nice.

<comment><USER12> Reddit has related links that no one uses. There is also a comment bot that finds reports. AI looks for Similar titles and site links. It's more complicated when trying to tailor it to a persons history. Digg and reddit have tried AI frontpage customization by history, but idk if it was ever to bring new people to catch up on old posts.

Facebook sort of did it with old posts randomly coming up on the side to trigger nostalgia I guess.

Taking into account vote history, you can tumble through old popular posts not similar to anything voted on yet. Maybe push it out to groups of people who haven't seen it to keep the comments and discussions to thrive.

Can use the API to gather the needed info

<comment><USER11> > Taking into account vote history, you can tumble through old popular posts > not similar to anything voted on yet. Maybe push it out to groups of people > who haven't seen it to keep the comments and discussions to thrive.

I like this. Also instead of a related link, just show the related things. And maybe stack overflow style user moderation.

</comment></comment></comment><comment><USER13> This is a TED talk by the creator of think.com: [http://www.ted.com/talks/danny_hillis_the_internet_could_cra...](http://www.ted.com/talks/danny_hillis_the_internet_could_crash_we_need_a_plan_b.html)

He touches on his early realization that he could have taken a ton of domain names & made some money, but that would have gone against the spirit of the internet at that time (i.e. don't take more than you need.)

</comment><comment><USER14> Sad to see that "think.com" is so underused. Oracle would do well by me to donate it to one of the many educational initiatives for use today (think.com resolves to this [http://www.thinkquest.org/en/](http://www.thinkquest.org/en/))

Recently I went looking at the registration for love.com, but that was a relative newbie, being registered in 1998. How did it take so long for someone to snatch that up? (sadly, that too is being wasted by a corporation: AOL)

<comment><USER15> Totally agree. It's a shame there isn't a rule in place whereby domains need to be used or handed back.

<comment><USER16> Problem with such rule is how would you define "used domain". For example I own one domain whose almost sole purpose is that it is part of package name in few Java systems written 10 years ago (and few hostnames belonging to that domain are in configuration of who knows how many things).

<comment><USER17> With real estate property taxes encourage an efficient distribution of resources. The domain fees could increase, however it would be difficult to assess the value of a domain for a property that is so nonfungible that it is only valuable to the company that has a made up word as its name.

</comment></comment></comment></comment><comment><USER18> This reminds me of a book published, back in the early 90's that contained a list of every public email address on the internet. It was smaller than the average phone book.

I imagine an updated edition would be a little larger. Or have really tiny type...

</comment><comment><USER19> So why was Symbolics first?

<comment><USER20> It was an MIT AI Lab spinoff which helps explain why it was early. As to why it was earlier than, say, BBN though I have no idea.

<comment><USER21> BBN has an entire /8 for itself at 184.108.40.206. I'm sure whoever made that decision saw there were maybe a dozen addresses and figured, "whats the point? people can reach us at 18.104.22.168."

</comment></comment></comment><comment><USER22> Interesting to compare this list to the current Fortune 500 list to get a list of companies that were first on the net and also managed to stay very profitable over the last couple of decades.

Just from a glance, looks like IBM and AT&T made both lists. I'm sure there are others.

<comment><USER23> Northrop.

</comment></comment><comment><USER24> Previous occurrences/discussion of same thing here:

[https://www.hnsearch.com/search#request/all&q=oldest+domains...](https://www.hnsearch.com/search#request/all&q=oldest+domains&start=0)

</comment><comment><USER25> Anybody got older snapshot?

[http://web.archive.org/web/19981207002851/http://stony- brook...](http://web.archive.org/web/19981207002851/http://stony- brook.scrc.symbolics.com/www/index.html)

<comment><USER26> [http://web.archive.org/web/20031206082643/http://stony- brook...](http://web.archive.org/web/20031206082643/http://stony- brook.scrc.symbolics.com/www/index.html)

this one is the latest worthy snapshot

</comment></comment><comment><USER27> The Wayback Machine let me down again. Until I waybacked the Wayback Machine.

</comment><comment><USER28> Interesting that some companies really advertise on the oldest domain, [http://symbolics.com](http://symbolics.com). (Or it's fake so others want to advertise, too.)

<comment><USER29> An aged domain typically has higher page rank. I imagine it has a ton of backlinks from just existing in that time. Companies pay for its page rank to be funneled into them by association.

<comment><USER27> Looks like it's someone pretty excited to have it: [http://symbolics.com/about-symbolics/](http://symbolics.com/about-symbolics/)

</comment></comment></comment><comment><USER30> As someone who was being born when those domains were being registered, can anyone shed some light onto what the internet was like back then? (my understanding is that there wasn't a www back then)

<comment><USER31> I finished my studies in 1993 and I have used internet a lot during the 3 last years (mid 1990 until mid 1993). ncsa mosaic has really arrived in my school only at the beginning of 1994, after I left.

During my studies, the main internet tools were telnet and ftp. There was no firewall and it was really easy to connect to any computer anywhere. It was also really easy to find password (ypcat passwd then dictionary based attacks). My girlfriend was in another school (500km away) and I was using a small utility named xhtalk to monitor when she was connected in order to chat with her. With xarchie, you could search a software or game by its name and it returned an anonymous ftp server.

I played go on internet using igs in 1992. There was something similar for chess.

The main information source was the newsgroups. There was already hyperlink navigation with gopher.

The version of linux on my PC was 0.99 (version of the kernel). I was using it mainly as an X server to access the school computers when the rooms were closed.

</comment></comment><comment><USER32> Has anyone gotten in early on namecoin domain names? There are still a lot available when I checked. Unfortunately the process seemed really complex so I kind of gave up for now. Any thoughts?

</comment><comment><USER33> Ha - #69 = my first name - kai.com - registered by Intel - I guess they are looking after it for me : )

</comment><comment><USER34> I recommend not visiting symbolic.com. Tacky advertising and nothing else.

</comment><comment><USER35> IBM, HP, Apple, Intel are right there. I didn't see Microsoft though.

</comment><comment><USER36> The oldest item on that list is one day older then I am...

</comment><comment><USER37> dig @new.toad.com toad.com -t AXFR

wutttttt</comment>


A second life for very old C programs - <AUTHOR> https://tailordev.fr/blog/2017/03/24/second-life-for-c-programs/ <comment><USER3> If you have these compiling with a modern toolchain, you may wish to ditch the python subprocess wrapper and compile them with something like emscripten (compile to javascript) or NestedVM (compile to JVM bytecode). Then you won't be exposing 30 year old unsafe code directly to the internet... at least it would sandboxed. If you use emscripten you could even have the programs run client side.

I have a fork of NestedVM that I've been using with success but I don't have any simple examples for you:

[https://github.com/bgould/nestedvm](https://github.com/bgould/nestedvm)

Here is an example of compiling the Apache Thrift compiler to run on the JVM:

[https://github.com/bgould/thrift/tree/nestedvm/contrib/neste...](https://github.com/bgould/thrift/tree/nestedvm/contrib/nestedvm)

And I have a version of the toolchain precompiled as a docker image:

[https://hub.docker.com/r/bcg1/nestedvm/](https://hub.docker.com/r/bcg1/nestedvm/) [https://github.com/bgould/thrift/blob/nestedvm/contrib/neste...](https://github.com/bgould/thrift/blob/nestedvm/contrib/nestedvm/docker/build.sh)

<comment><AUTHOR> Very nice, thanks! Third time I read something like this today, so worth considering I guess. Thanks a lot for the links!

</comment></comment><comment><USER4> How does it compare with the classic approach of providing a JavaScript emulator for the binaries?

This is what the archive.org Software Library does.

MSDOS Games: [https://archive.org/details/softwarelibrary_msdos_games](https://archive.org/details/softwarelibrary_msdos_games)

Atari 2600: [https://archive.org/details/atari_2600_library](https://archive.org/details/atari_2600_library)

etc.

<comment><AUTHOR> Thanks. I did not know about it to be honest. Very interesting!

There is no comparison since the idea was not to port the programs to JS or in the browser but rather being able to compile them (with a common setup) and create an API on top of them :)

<comment><USER5> If you don't need multiple people to interact with shared data maintained by the same program, and instead everyone's interactions with the program can run independently, then you could still run the JavaScript version of DOSBox on the client side, and extend that version of DOSBox to offer JavaScript APIs to communicate with the virtual machine running inside. For instance, to send or receive characters, or modify files on the virtual disk.

<comment><USER6> That sounds awfully much more complicated.

</comment></comment></comment></comment><comment><USER7> > _these software have been written for MS-DOS and therefore require a rather > old computer to use them_

There are quite a few options to run MS-DOS applications on modern hardware.

<comment><USER8> If you give that sentence more context, it becomes clearer what the author was hoping to be able to do with the old code. It's not merely "keep this old DOS accounting app working for the local auto mechanic".

> First, these software have been written for MS-DOS and therefore require a > rather old computer to use them. This leads to two more issues: not everyone > can easily use them, and it is nearly impossible to interface them with > other software.

> We have been asked to build a Proof Of Concept (POC) to transform these > programs into web services in a week

This person is a museum curator, so there's a good reason (society benefit) for their desire to transform something from the old computing world into something people can appreciate and understand in today's context.

<comment><USER9> This is not a 'curation' worthy event, in my opinion. A more accurate presentation would be to have the DOS machine 'in the flesh' (i.e. a booting example of the ol' PC). When that's not happening, the next best thing is emulation.

Re-compilation, cleverly disguised as 'auto-configuration' in this case, is pretty much a total fakery.

</comment></comment></comment><comment><USER10> 1987 isn't very old. There is easily code in, oh, Vim which is that old, and gets used daily.

(No _double entendre_ intended here with "gets", by the way.)

<comment><USER11> Though I'm sure you meant this casually, and yes, vim has been around quite a while, vim is not vi.

[https://en.wikipedia.org/wiki/Vim_(text_editor)](https://en.wikipedia.org/wiki/Vim_\(text_editor\))

" Vim (/vɪm/;[3] a contraction of Vi IMproved) is a clone of Bill Joy's vi text editor program for Unix. It was written by Bram Moolenaar based on source for a port of the Stevie editor to the Amiga[4] and first released publicly in 1991. "

[https://en.wikipedia.org/wiki/Vi](https://en.wikipedia.org/wiki/Vi)

" The original code for vi was written by Bill Joy in 1976, as the visual mode for a line editor called ex that Joy had written with Chuck Haley.[2][3] Bill Joy's ex 1.1 was released as part of the first BSD Unix release in March, 1978. It was not until version 2.0 of ex, released as part of Second Berkeley Software Distribution[4] in May, 1979 that the editor was installed under the name "vi" (which took users straight into ex's visual mode), and the name by which it is known today. "

" In 1989 Lynne Jolitz and William Jolitz began porting BSD Unix to run on 386 class processors, but to create a free distribution they needed to avoid any AT&T-contaminated code, including Joy's vi. To fill the void left by removing vi, their 1992 386BSD distribution adopted Elvis as its vi replacement. 386BSD's descendants, FreeBSD and NetBSD followed suit. But at UC Berkeley, Keith Bostic wanted a "bug for bug compatible" replacement for Joy's vi for BSD 4.4 Lite. Using Kirkendall's Elvis (version 1.8) as a starting point, Bostic created nvi, releasing it in Spring of 1994.[28] When FreeBSD and NetBSD resynchronized the 4.4-Lite2 codebase, they too switched over to Bostic's nvi, which they continue to use today.[28] "

<comment><USER10> No, I meant Vim very specifically, because I know Vim to be based on sources dating to 1987 or older, and I know it to be in daily use.

I used the original Elvis in the early 1990's a bit and am aware that nvi is based on it. I don't know off the top of my head how old Elvis is. I don't know whether Joy's vi code is still in use anywhere, either; obviously it isn't in any of the BSD's that use nvi.

Probably the vi in AT&T derivatives (Solaris, etc) has Bill Joy code in it. Does Solaris receive daily use involving invocations of vi? That is the question ... haha!

</comment></comment></comment><comment><USER12> How big are these programs? Isn't it better to just commit them on GitHub and have volunteers rewrite them nicely in something modern?

</comment><comment><USER13> This is very cool and something I have been curious about for a long time. How is the performance?

<comment><AUTHOR> Surprisingly pretty good. Simple API load tests show response time < 80ms. The C programs themselves are very fast (because there is not a lot of computation involved).

</comment></comment><comment><USER14> Older C programs were made before many well-known security attack vectors were discovered. e.g: the first exploitation of the buffer overflow came in 1988.

So be careful. Take measures so people do not exploit those vulnerabilities, such as executing arbitrary code in your machines.

<comment><USER15> Actually it was already acknowledged by the C designers in 1979 that not everyone was writing good C code, hence lint.

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."

[https://www.bell-labs.com/usr/dmr/www/chist.html](https://www.bell- labs.com/usr/dmr/www/chist.html)

<comment><USER14> While it is true that in 1979 buffer overflows were known by researchers, it wasn't until much later when it started being exploited in the wild.

<comment><USER15> The problem with security was already well known:

"The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - <USER2> already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

\-- The Emperor's Old Clothes By C.A.R. Hoare Communications of the ACM, 1981

As for exploits in the wild, before the UNIX worm there were the game cheats on home micros.

<comment><USER14> Buffer overflows were discovered earlier than that, in 1972.

[http://csrc.nist.gov/publications/history/ande72.pdf](http://csrc.nist.gov/publications/history/ande72.pdf)

However regular C programmers in the 70s and 80s were not defending themselves against arbitrary code execution from buffer overflows.

In addition, you can take C programming books from the time and see how functions like memcpy and strcpy were being used in unsafe ways.

That is my point. If you are going to reuse old programs, be aware that in earlier decades there wasn't as much awareness about security as there is today.

</comment></comment></comment></comment></comment><comment><USER16> It's a DOS to Gnu conversion. 1990s dream come true.

</comment><comment><USER17> Nice work.</comment>


Using TypeScript with React - <AUTHOR> https://simonknott.de/articles/Using-TypeScript-with-React.html <comment><USER2> Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case.

IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. I've been in CTO type roles and already insist on it when I can. I don't think I'm alone in this and many organizations only do typescript at this point.

<comment><USER3> _> If it's tedious, you're probably doing something wrong or sub-optimal._

 _> IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional._

Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arrogantly spout their opinions about system design as if they had been correct about everything all along. Not "these are the benefits, these are downsides" not "I've improved in X by using Y", always "nobody needs X, everyone must do Y, and if you're not doing Z you're wrong and unprofessional". Zero self-awareness.

<comment><USER4> The problem IMHO is the old adage of the devil being in the details. I see a lot of engineers talking about things like deriving types from enums, and meanwhile the type system will merrily let you do this:

        type Foo = {a: number}
        const o: Foo = JSON.parse('null')
        o.a = 1

It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilities, but they just shrug when I point out that the foundation of the scheme is still unsound.

<comment><USER5> This is the equivalent of casting in Java. Is Java's type system unsound?

<comment><USER4> You can't cast from a HashMap to an Animal class in Java, so in that sense Java is sounder. But you can still do `Animal a = null; a.walk();`, so in that sense, Java isn't sound.

<comment><AUTHOR> Correct me if I'm mistaken: I think you can indeed cast from HashMap to Animal and it will happily compile:

```java

import java.util.HashMap;

class Main {

      class Animal {
        String sound = "roar";
      }

      public static void main(String[] args) {
        HashMap<String, String> map = new HashMap<>();
        Animal animal = (Animal) (Object) map;
        System.out.println(animal.sound);
      }

} ```

At runtime, this will crash with the following Exception: `Exception in thread "main" java.lang.ClassCastException: class java.util.HashMap cannot be cast to class Main$Animal`, but it will satisfy the type system.

<comment><USER4> Oh right, I totally forgot about casting to Object! So much for "sort of sound" haha

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I've been writing Typescript with React for quite a while now and these are my feelings so far:

\- Typescript type system is pretty awesome, and allows the expression of some things really elegantly; in particular, string literal types are quite cool for component props that feel "htmly", union and intersection types are great for making reusable/generic components and Partial<T> is cool for making typesafe component states ([https://www.typescriptlang.org/docs/handbook/advanced- types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html) is a great resource)

\- on a related note, the Typescript docs are very comprehensive

\- ... but docs for anything React related to Typescript (types of components, etc) are harder to come by

\- for the actual UI code there is some time wasted getting type signatures perfectly correct, particularly for React and HTML components, but I've built up a bank of helper functions in this regard.

\- using `any` nearly always comes back to bite you as you trick yourself into feeling typesafe

\- there is always a tradeoff between having perfectly exact types and not writing 139587123598 interfaces; expressing, for instance, mapStateToProps, mapDispatchToProps and mergeProps to compose into component props, or the former as a subtype the latter is pretty fiddly to get right and imo not worth the extra code

\- create-react-app typescript support has gotten pretty good now, but it's nigh-impossible to step outside their boundaries. For me, some older features of typescript I wanted that protobufjs generated typescript used was just not usable and I had to work around that with great difficulty

\- nearly all packages now have type definitions for them which is sick

\- at the end of the day, you can still resort to vanilla JS where typescript really, really gets in the way

<comment><USER7> > ... but docs for anything React related to Typescript (types of components, > etc) are harder to come by

I just saw this linked today and didn't look it through entirely, but this React+Typescript cheat sheet looks very interesting for React-specific issues you might encounter with Typescript:

[https://github.com/typescript-cheatsheets/react- typescript-c...](https://github.com/typescript-cheatsheets/react-typescript- cheatsheet)

For example it explained an issue with the type inference for custom hooks that confused me somewhat earlier.

I really like Typescript so far, but you can easily encounter situations that are hard to figure out with only basic Typescript knowledge, especially when interacting with more complex libraries. This probably gets better with more Typescript experience, but it can be a serious speed bump as a Typescript beginner.

<comment><USER8> This is wonderful, and probably a better strategy than the one I've employed (e.g. hovering the onClick attribute of some component, seeing what type pops up in VSCode, copying it, and using that for my type, done!).

</comment></comment></comment><comment><USER9> I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anymore so I can't figure out which versions it used to resolve to …

The @types definition packages for react-router, redux-thunk, etc. give me "error TS2605: JSX element type X is not a constructor function for JSX element". Most popular answer on GitHub is to rm -rf node_modules and rebuild, however that does nothing for me. I tried upgrading some @types selectively and triple-double checked that the resolved versions make sense, but nothing so far.

A codebase that used to build cleanly now throws ~30 errors on build, without _any_ changes to it. Insane. Always pin your exact versions in JS land …

<comment><USER10> > now throws ~30 errors on build

Yep, it's a beautiful technology, total type safe heaven.

Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time.

I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.

<comment><USER11> >> Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

That should be at the top of every page on the TypeScript documentation website. It would save developers so much suffering.

>> All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time.

I'm still looking forward to the TypeScript version when they invent dynamic typing and enforce it at compile time.

I have similar experiences. What I've found is that a team which can build a high quality application in TypeScript is generally capable of building an even higher quality application in JavaScript in half the time and with better, higher quality test coverage.

>> I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.

I look forward to this glorious day. Short live TypeScript!

<comment><USER12> I do find it rather strange that strongly typed code with no errors, that builds correctly, can fail at runtime due to type errors. My JS oftentimes ends up nicer than my TS because I don't have pages of, basically, type-level administrative work.

I don't have this experience at all in other strongly typed languages, including _very_ strong ones like Haskell/PureScript. The types there just work for me.

<comment><USER11> This can happen if handling data from a remote client. Type checking does not happen at runtime so you still need to do your own schema validation even with TypeScript. So IMO it adds almost no value.

<comment><USER13> in which case your API layer should validate the data at runtime so that it only actually returns type T as it claims. then you are back to soundness

</comment></comment></comment></comment></comment></comment><comment><USER14> Disappointed that the article alluded to but never explains why classes should be avoided in Typescript. (Which I agree, btw)

If you're used to classes, it's really tempting to create classes for your models. But in Typescript, which gets compiled down to plain old JavaScript, you spend a lot of your time dealing with JSON and plain old JavaScript objects (POJO). These don't have methods. These don't have private members. These don't have constructors.

You actually don't need any of that. You just want type safety around your JSON and POJO. That's why more often than not, you're going to be using interface.

I'm not saying never use classes. But don't use classes to define models. Use classes for controllers.

<comment><USER15> This sounds very arbitrary, opinionated, and unconvincing. If a class is a co- location of data and methods performed on it, then how is this class:

      class Foo {

        constructor(value) {
          this.value = value;
        }

        addOne() {
          this.value++;
        }

        getValue() {
          return this.value;
        }

      }

      const foo = new Foo(1);

any worse than this POJO:

      const foo = {
        value: 1,
        addOne() {
          this.value++;
        },
        getValue() {
          return this.value;
        }
      }

Besides, what are models and controllers in React codebases, and why is using classes for one of these groups any better than for the other?

<comment><USER16> I think you missed the part where they said you don't need classes for POJOs and models i.e. things which only contain data and do nothing else. If you want methods that operate against the inner data of an object then totally write classes

<comment><USER15> It's just that they started their post by saying that classes in Typescript should be avoided. A message "x should be avoided" is very different from "you don't need x". Compare the statement "you don't need redux", which has been incorporated into titles of numerous blog posts, with the statement "redux should be avoided".

</comment></comment></comment></comment><comment><USER17> I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been:

\- Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If the usage going to persist (example, using a library without @type), then you treat it as JS and have appropriate amount of validation around the occurrence.

\- Usage of "?" and "!" covers more scopes with less lines of code. For hobby/one-man project, I found their usages no-brainer, however I'm nervous when it comes working in a team of various experience level.

\- I've had real headache typing API responses. On one hand, you have absolute no control of others' code quality that you might as well have "number | string | null | undefined" for all parameters. But doing that almost defeats the purpose of typing it, so I'll need to use my educated guesses and judge reliability of each known parameters in responses.

\- TypeScript version of 'create-react-app' projects builds slower than its JavaScript counterpart without ejecting. It took 2~6 seconds per build while IIRC, it was <2 seconds for JS. I was keen to find a solution for this, but after a while it grow on me and I simple stop save after each line of code.

\- JSDoc is still relevant in TS code. It is great to document event emitters, exceptions etc.

\- tslint and prettier are must in my projects in order to retain sanity for unnecessary discussions around coding style.

<comment><AUTHOR> When it comes to API responses you don't control, I recommend taking a look at user-defined type guards: [https://basarat.gitbooks.io/typescript/content/docs/types/ty...](https://basarat.gitbooks.io/typescript/content/docs/types/typeGuard.html)

Also, +1 on tslint and prettier, they're great tools.

<comment><USER17> > type guard

Thanks for the link, I am currently doing something similar without knowing TS implicit behavior.

With 1st given example in the link, I forced on a style to such:

```

function doSomething(x: number | string) { if (typeof x === 'string') { doSomethingForString(x) }

      // Never do catch all to assume all non-strings are numbers
      if (typeof x === 'number') {
        doSomethingForNumber(x)
      }

      // Per transpiler rule, you not meant to be here, so error throwing is appropriate
      throw new Error('Unexpected type')

}

function doSomethingForString(x: string) { // Code }

function doSomethingForNumber(x: number) { // Code }

```

</comment></comment></comment><comment><USER18> During my internship we've built a large prototype using React+Typescript, and here are some of my key take aways from it:

      - Quite often when using unreleased APIs, you turn to using "any" all over the place.
      - Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features).
      - Lots of frustration when a package doesn't have types (although most major ones do have them).

Otherwise it has been a joy writing the application, and it does "document" your components significantly better.

<comment><USER19> Development time isn't slower when you factor in all the bugs it saves you from dealing with down the road when you're either wonder what is the type of an object or why something isn't working during runtime that a compiler could have caught.

<comment><USER8> Also, if you're working with an untyped APIs, define the types you're using. It doesn't have to be complete or perfect. But having that formal contract will save you time and make explicit your assumptions. In the best case, you can contribute those types to the API to everyone's benefit.

</comment></comment></comment><comment><USER20> React is more functional favored. It's very recommended for functional languages having static type systems, at least for language like JavaScript heavily relies on object literal.

The problem is, dynamic OOP languages like Ruby and Python are Okay to work with, since you know the class of an object you know a lot of things (schema, behavior, etc).

But for JavaScript and React, mutable classes are not quite useful since they mutate themselves, and could stop the app from re-rendering. it's more likely people are using object literals, which can hardly go far.

With TypeScript's structural and gradual type system, it's flexible and easy enough to type object literals with the union and intersection types, without forcing people to use classes.

</comment><comment><USER21> Typescript is awesome!!!

The creator of it answers "why typescript" in a video[1] with a hilarious answer which includes his observation that large javascript codebases become read only :-D

I'm giving a talk on typescript Friday. Some good stuff to understand is index signatures for object lookups, union types, intersection types, combining index signatures with named properties, and compile time immutability with readonly, Readonly<T>, ReadonlyArray<T>, ReadonlyMap<T>.

The language is so much fun to both write and read. There's a lot of depth to it as well. Excited to get to use it.

1\. [https://m.youtube.com/watch?v=wYgSiFaYSSo](https://m.youtube.com/watch?v=wYgSiFaYSSo)

<comment><USER11> >> javascript codebases become read only :-D

This is BS. I've built very large JS projects with hundreds of thousands of lines and never had this problem. If your architecture is well designed and modular then refactorings are easy and localized to just a small number of files. On the other hand, TypeScript encourages spaghetti code which makes refactorings span more files; complex active instances end up getting passed around all over the place and makes your code brittle and fully dependent on TypeScript to make any changes.

TypeScript allows you to write a lot of spaghetti code and allows you to delay having to think about architecture until your code is a total complete unmaintainable mess.

With JS, you will discover if you architecture is a mess a lot sooner and you will learn more and adapt faster.

<comment><USER21> Glad you enjoy large javascript projects and it works well for you.

Architecture is important regardless of what language you are using.

<comment><USER11> Thanks. I feel like there should be a lot less discussion about tools and a lot more discussion about architecture. I find that with good architecture, the language doesn't really matter at all.

I've built high quality very complex projects in both JavaScript and TypeScript (both alone and as a team lead). My point is that I (and people of my skill level) can complete the project/subproject much faster with JavaScript so it gives me a lot more extra time to write tests.

</comment></comment></comment></comment><comment><USER22> I see the same response everywhere on TypeScript: when a project becomes big enough, it's a good way to keep it under control.

And I tend to agree: types can be annoying, but when stability and robustness come into play, TypeScript is most certainly the way to go. It enforces good behavior.

And yeah, of course it slows JavaScript down, that's entirely the point..! JS allows you to do whatever you want, but that doesn't mean it's always the right choice

</comment><comment><USER23> If you are going to learn a new programming language for web UI, why not go for Elm ? You get so much more than just static types with Elm.

<comment><USER24> Looked at Elm and it looks quite interesting. however concerns for going to it

\- Skill transfer. If I learn react, I can use my JavaScript skill to understand how everything works under the hood. If I learn Typescript with React, knowing react, I can focus on learning new language feature while not learning at the same time how to build the application. With Elm, I have to learn the language and the framework, all at once, basically learning from scratch.

\- compatibilities with libraries. Here I definitely might be wrong, not knowing Elm enough, but okay, say you don't need a framework because it's included. What about utility library. Like i don't know, analytics or fancy animations?

\- Job Market. I'm not going to learn a language that I cannot use anywhere, and if I'm a company, I'm not going to choose a language for which is going to be hard to hire people.

Now Elm sounds real cool and I want to like it. But it doesn't seem very wise to spend time doing that vs learning something like Apollo+Graphql, or Typescript, or Vue, which have much more obvious benefits to my career.

<comment><USER23> The job market is a chicken and egg type problem. Management would not allow Elm based projects as there are no othe Em programmers on staff. We cant ask for Elm programmig experience in resumes as we dont have any Elm based projects.

I wonder how other languages,like Scala, managed to get traction in the enterprise whereas Elm has not even though it can solve real issues that we face with Javascript development.

<comment><USER25> Scala got traction in places I've worked partly by making the pitch that the team hires people based on software engineering aptitude, not prior knowledge of specific technologies.

A new hire often has to learn a number of new/different technologies. The language is one of the easiest of those.

</comment></comment></comment></comment><comment><USER26> "TypeScript solves problems that I don't have, in a way that I don't like."

<comment><USER27> What are the problems that Typescript solves that you don't have?

</comment></comment><comment><USER28> The whole discussion of typed vs untyped is stupid. Types and structures are all around us (albeit simple or infinitely complex, eg inductive vs coinductive). It is rather a discussion about typesystems that check type constraints immediately before shipping and/or after shipping while running the program. Without a proper typesystem the programmer has to check the types in his mind, or the end user gets a runtime error. For small hacks or prototyping type checking is not really required because of low overhead. But in non trivial larger, long running systems with a lot of maintenance the cognitive overhead is too big to not use a typechecker. Even if you decompose in microservices or microfrontends you still stuff like schema definitions and IDLs. Even hardcore ecmascript evangelists use linters extensively before shipping (potatoe/potato linter/typechecker)...

</comment><comment><USER29> I just want to stop using JS on the browser side.

We can compile C to WASM, which gives us effectively most dynamic languages on the browser. Say Python. I have a plan to put a tiny web framework together just having Python doing the front end stuff. Not react or anythng but enough for "most" use cases (I know I know)

But JS just feels like it changes too fast, its been well over a decade of wheel-reinventing when the fundamentals of tabular display, layout and so forth have to be relearnt every year or two.

<comment><USER30> Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates.

Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.

<comment><USER29> I disagree.

JS _should_ be like SQL - everyone's second language and a _standard_ that can be taken from job to job and company to company and still be effective.

But while I this week used my decades old SELECT skills for a quick two day job, I have also been utterly stumped trying to modify react codebases.

JQuery is probably the closest thing to SQL in the JS world and it is fine - but there appear to be few technical reasons not to use it and lots of fashion reasons.

And so while I could just stick to JQuery and some widgets, the weight of development seems to be in the morass of _change_ that is so very hard to stay on top of.

Yes this feels like crotchety old timer moaning, even to me. But there is something there. I am having trouble expressing it however.

<comment><USER30> Client development was never trivial. Your old iOS/Android skills also expire due to SDK changes. Apple recently switched out the entire language you're using.

I don't think SQL is a great example either. Your next company could be using any database where you aren't even writing SQL. And you're expected to know more than standard SQL to, say, use Postgres. Your rant here to me is like getting mad that "just SQL" isn't enough because you constantly have to learn more at your next job that uses Postgres, DynamoDB, etc or that "just <language>" isn't enough because your next job uses a different framework than you're used to. I don't think your rant is consistent, so it just comes off as confused anger towards JS client development.

Maybe you don't have the stomach for client development where code must run on a machine you don't control? That isn't a disparaging remark either, it's very reasonable to prefer the cozier environment of writing code for machines you do control (like application servers).

</comment></comment></comment></comment><comment><USER31> I get why TypeScript is quickly becoming the standard, but the problem with it is that it's still JavaScript, and contains all the warts thereof. If at some point your attention turns to the very real benefits of static typing, why not choose an objectively better language?

That's why after ~10 years of being a JS/Node developer, I switched to Dart, not TypeScript.

</comment><comment><USER32> For typescript to be very useful to indispensable the tooling needs to improve.

If there was a checkbox on VSC that said "use typescript" for a project and I had to do _nothing_ else for it to work then sure, I'd use it.

For a single dev working on a fairly simple React + Redux app it'll slow you down like no tomorrow.

<comment><USER33> What you're asking for _mostly_ exists. You don't even need a checkbox.

TypeScript support has been included with create-react-app since v2.1.0, with all the features enabled. VS Code ships with syntax highlighting and command completion for TS.

If you want to try it use;

        npx create-react-app tsx-test
        yarn add typescript @types/react
        mv ./src/App.js ./src/App.tsx
        yarn start

(WARNING: npx runs stuff from the internet on your machine)

That will make a 'typescript' React app run on your machine. Obviously App.tsx isn't actually doing any TypeScript stuff, but if you add some it will work.

<comment><USER34> Note that they said "React + Redux". And that combo indeed takes a lot more time to get set up and understand the first time.

I used this lib to get it to work: [https://www.npmjs.com/package/typesafe- actions](https://www.npmjs.com/package/typesafe-actions) I wouldn't even know how to get it to work with just the regular react & redux types.

<comment><USER33> typesafe-actions looks useful but you don't strictly need it. You can use redux with TS just by adding @types/react-redux. [https://redux.js.org/recipes/usage-with-typescript#usage- wit...](https://redux.js.org/recipes/usage-with-typescript#usage-with-react- redux)

</comment></comment></comment></comment><comment><USER35> Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive.

My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

<comment><USER36> I feel almost the exact opposite: TypeScript is delightfully terse _while_ still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript.

You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nasty level of boilerplate. (They can also be implemented with an abstract class if that's more your bag.)

It lacks pattern matching because it intentionally doesn't include a runtime component, which I think is also wise. Options exist if you want to use them. I've seen people use Purify to good effect.

<comment><USER35> I guess it depends on what you compare with. If you're coming from Java or the like, surely TS does not feel particularly verbose.

However, coming from a truly terse language like Haskell you'll just feel TS is too verbose and not very elegant. TS is the most verbose and least elegant of the languages I'm personally using, on par with Dart.

ADTs not only feel dirty because they're not first class citizens (you build them with the TS primitives by adding a discriminating union key) but also somewhat useless since you don't have pattern matching.

Although pattern matching would not be a trivial problem to solve in TS. It could be solved with the compiler, however, you'd still have to hack the compiler API quite a bit too and TS doesn't even support integrating custom extensions with a config file like Babel does.

Btw thanks for pointing me to that ts-purify, it looks good!

<comment><USER36> I'm sure that, if you're carrying a torch for Haskell, TypeScript can feel very primitive--though I don't enjoy writing Haskell, in my experience it turns into an exercise in navel-gazing and write-only code compared to TypeScript or F#--but on the other hand _normal people can write it and be productive_ and that's kind of important, yeah? I think the TS folks did a great job in making something that I can bring into engineering shops to make average to average-plus developers significantly better and significantly safer.

I'd really disagree with the notion that discriminated unions/ADTs are useless; the compiler is clever and will constrain the type in an `if` or a `switch` (particularly useful with an enum type, too). I use this regularly and it's really effective; my `nestjs-auth` library makes it more or less a requirement and its users seem to really dig it. And if you do it as an abstract class instead of a key, you can use polymorphism to take care of a lot of what would otherwise be pretty clunky--this is how you can make a solid maybe/option type in the vein of Scala.

<comment><USER35> Hehe yes the Haskell community certainly suffers from the dynamics you just described.

I guess my problem with TS ADTs is just that they're done with the TS primitives whereas they could be true first class citizens. But such a feature may be too hard to swallow for your typical JS developer whose first introduction to types is Typescript.

Btw can you elaborate on that Enum with ADTs? Or did you mean that you use Enums with switch-case? I use it too and find it one of the best bits of TS.

<comment><USER36> I do mean enums/switch, yeah. Makes it easy to have your code yell at you when all cases aren't dealt with.

The thing about making ADTs first-class citizens means that TypeScript stops being JavaScript, and one of the most valuable parts of TypeScript to me is that I can just look at it and know what the underlying JavaScript is. I kind of equate it to writing C on an old platform--it's going to be munged significantly but at a glance you can have a high degree of confidence that the code coming out the other end is going to be what you expect it to be.

</comment></comment></comment></comment></comment></comment><comment><USER37> In 2019 is this article adding anything to our collective knowledge? There's nothing new here at all.

</comment><comment><USER38> React is already typed with props. I see no added use for TypeScript. Yet another list of packages makes maintaining very hard and inconsistent (as types are declared in variant ways). Explicit (and simple) functions as React (e.g. hooks) provides won't need strongly typed code, less readability in my opinion.

If you're building a library / sdk, than Typescript comes in place and can make life easier for devs.

<comment><USER39> PropTypes are disabled for production builds and runtime only.

The only advantage for using them over TypeScript or Flow that I've seen is when consuming third party React components.

Otherwise the guarantees, feedback loop and terseness of static types are superior to PropTypes.</comment></comment>


HSBC Bank on Verge of Collapse: Second Major Banking Crash Imminent - <AUTHOR> http://iacknowledge.net/hsbc-bank-on-verge-of-collapse-second-major-banking-crash-imminent/

<comment><USER2> this is dumb and irresponsible,

banks have insurance up to a limit, if you are over that after 2008 you deserve it :/

now, making every clueless person rush to take money out is a sure way to create a bank crisis. even if there wouldn't be one.</comment>