13 ms·

Tech Choices I Regret at Spectrum

309 points by theBashShell 8y ago

andonisus 8y ago
Was using node over another language/ecosystem a baked-in requirement?
- mhd 8y ago
  A chat application is to node.js what a blog was to Ruby on Rails or PHP -- it's basically the default example of every framework and library. Low complexity, high throughput. So you'd have no trouble finding good examples and libraries. For a while, Erlang was quite popular in that area, but as some orgs only used it for that and thus didn't get too deep in the tech stack, they were eager to switch to something they imagine they know a bit better.
  - k__ 8y ago
    Erlang had the problem that it got more popular at the same time as the rise of Go happened, which also played the back-end-concurrency game.
- mxstbr 8y ago
  The only programming language we all know is JavaScript, so it was not an option to go with another backend language. I would love to learn Elixir though, from what I have heard it is great for real-time!
catears 8y ago
I am right now on the train home from work quite late (22:40 local time). The reason I spent so long at work today is because we update after 8 o'clock. However, we found a critical bug in some open software that we use that we do not know why it triggers. We barely even know how it happens! Of course we haven't been able to solve it yet... After personally spending a lot of time with trying to fix the software I can say that I have gotten a much deeper appreciation of tools that are widely used and with an active community, where most bugs have already been solved. Previously I had believed if you had a tool that solved the exact problems you have, then you should use it. I hope I'll resist such an urge in the future by having a little pragmatic angel on my shoulder reminding me of the danger of underused software. No software is perfect and even tough you might be able to fix software when it is open source, you paint yourself into a corner when you will necessarily have to fix it. I felt my experience was matching some of the authors woes and I urge anyone that chooses technologies to think one step ahead and learn from our mistakes!
- quickthrower2 8y ago
  To avoid burning out I suggest: 1. Deploy 2. Test deployment 3. If success, great go home at 8:10pm. 4. If fail, rollback, retest, go home at 8:20pm. Come in next day and fix in source code and schedule new deployment. 5. To avoid #4 in 99% of scenarios, use a staging environment.
  - opportune 8y ago
    In my experience staging environments only work in a few (very common) use cases. When I do big data work I certainly use a test environment but we can't just replicate all the data in two clusters because that would be absurdly expensive - and this makes testing performance basically only possible in prod. I'm sure basically any database system with a non-trivial amount of data has the exact same issue. But staging definitely works for something like a web server
  - catears 8y ago
    Luckily we have "update nights" at most once every other month. But the workflow you describe is what I would want in the end. I work in a small startup tough so change is happening rapidly to make these processes better. It's far from institutionalized! We do however have a staging environment already that is frequently updated and updates available within an hour from starting the update. Thanks for the concern and tips nonetheless!
jessaustin 8y ago
Some of these seem difficult to predict. If you knew in advance that Github would acquire, WYSIWYG over markdown wouldn't have been a priority. You couldn't have known that, however. Developers know markdown, web creatives know markdown, but does anyone else?
- mr_toad 8y ago
  > Developers know markdown, web creatives know markdown, but does anyone else? Randoms who comment on Reddit. It’s not a high bar. I actually prefer using markdown than fighting with an opinionated WYSIWYG editor. (Looking at you Word).
- mxstbr 8y ago
  You are inverting the reasoning. GitHub bought us because our main audience is developers. We should have stuck with markdown, because our main audience is developers, not because GitHub also saw that and acquired the company.
TimTheTinker 8y ago
I clicked on this hoping this was the "Spectrum" cable ISP. We don't hear too often from ISPs and infrastructure companies on HN.
- teej 8y ago
  There’s also an AWS offering called Spectrum and a data enrichment platform called Spectrum. Pretty overloaded name.
  - acemarke 8y ago
    Not as bad as "Jetpack" :) https://news.ycombinator.com/item?id=18819708 https://news.ycombinator.com/item?id=18819708
  - Junk_Collector 8y ago
    There's also an engineering trade magazine called Spectrum. It's everywhere.
    - 4thaccount 8y ago
      IEEE Spectrum has been around for a long time and is one of the reasons I became an engineer. I can still remember tearing into the article on the DARPA Autonomous Robot challenge.
  - nineteen999 8y ago
    You could monitor your AWS Spectrum and data enrichment Spectrum with Spectrum by CA Technologies.
- AnaniasAnanas 8y ago
  Thought that it was about ZX Spectrum by Sinclair.
  - IggleSniggle 8y ago
    And here I thought it was about a technologist working at the vitamin company, Spectrum.
kodablah 8y ago
On the side I'm building a communication app myself and I've started over a few times now. I made some mistakes in early development that caused starting over to be the best choice (I'm not a perennial start-over guy, things weren't very far along when I restarted, this is just a side thing). Mistakes: I did plenty of backend work (e.g. gRPC services) just to realize it didn't mesh well with the frontend when I started to build it. I over-complicated the feature set and realized I built a foundation for an MVP that would take forever. I abstracted everything because in my head I thought about all the future uses. I worked on an advanced-tech frontend that kept me bogged down in frontend development instead of doing the whole thing. All of these are typical mistakes of pie-in-the-sky side projects sans deadlines. For the latest iteration I have changed my approach. I am building the dumbest web UI w/ the dumbest in-memory-only-at-first backend with minimal abstractions. The initial web UI doesn't even use any JS which I know can seem like extra work w/ HTML forms and the like, but the raw simplicity is easier to build now and take away later than something more complex. I'm deferring lots of features. Once I reach a web-UI-only MVP, my next step will be to abstract what already isn't on the UI front and make a Qt app that uses the same abstraction. I've found this to be the easiest way to get some UI idea reuse across different paradigms. I can add more UIs including an API, terminal, mobile, etc with this approach. For the backend, simple gRPC backed by a "db" of in-memory data structures for now until I abstract that to allow sqlite to join and then on from there. It is very refreshing to develop a full-stack app without a complex full stack. The major benefit of developing a stupid-web-with-in-memory-db MVP? Testing and quick iteration. I've found you can iterate on core structures/ideas or you can iterate on external tech/features, but you can't do both at the same time.
saagarjha 8y ago
> We are building native apps now, but starting from scratch is time consuming. If we had used react-native-web to build the website, we could have reused the base components and built the native apps much faster! > Optimize for iteration speed and flexibility. Faster, but not necessarily better. Reusing web technologies for mobile is almost always an optimization for developer time, which might work early but I feel almost always ends up needing to be rethought in the future.
- rhizome 8y ago
  The phrase "optimize for iteration" feels like something you do when you don't know what you're doing. They say experienced developers spend most of their time thinking, vs. writing code, and so with inexperience you don't have the tools to eliminate iterations in your head.
  - nostrademons 8y ago
    In a startup, by definition you don't know what you're doing. Once you know what you're doing, it's not a startup, it's an established business. Once everybody knows what you're doing, it's called an industry. It's usually fruitless for a startup to chase after problems that everybody knows how to solve, because somebody has already solved them, probably better than a small team of junior developers can. Experienced developers spend most of their time thinking because experienced developers tend to work in fields where at least the problems are known, as well as some best practices for solutions. That's how they got to be experienced, after all. But this is also why experienced developers, when they choose to found startups, often end up with B2B startups that slot into an existing industry structure, not startups that end up defining the industry. (Source: experienced developer now founding a startup and wrestling with just how little all that experience matters when it's not even clear what problems will dominate the industry or if the industry will even come to exist.)
    - saagarjha 8y ago
      The tools for making a mobile application is something that I consider to be "solved", except in some very specific cases. If you are a startup, you are likely innovating in something that is not making apps, so I do not agree that you "don't know what you're doing" in this area.
stockkid 8y ago
It seems contradictory to me that author learned to "deliberately assess cutting edge technologies, bias towards conservative choices," yet he regrets not using react-native-web and Next.js.
- j2kun 8y ago
  Wait until the author hears about react-native-web-native, the go-to solution for using your react-native-web components in a native environment!
  - sephoric 8y ago
    I honestly can't tell from your comment if that really exists or is satire.
    - kbenson 8y ago
      Neither can I. I'm I'm leaning towards it existing but being used as a vehicle of satire, because that's just how crazy the world is now.
      - navs 8y ago
        https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web
        stronglikedan 8y ago
        I don't know why I find it so funny that the browser's back button doesn't work in the examples[0]. [0] https://necolas.github.io/react-native-web/examples/ https://necolas.github.io/react-native-web/examples/
        ollerac 8y ago
        Because re-implementing native browser features that are core to an application's usability is a hard problem that "cutting edge" web frameworks open you up to?
k__ 8y ago
I worked at a startup that used RethinkDB too. Change feeds sounded cool, but we never used them in the end, because of the latency. I didn't use react-native-web, because back in the days it was alpha and later there was react-native-dom, which seemed like a better approach, but I have the feeling it doesn't have much pace to get anywhere any time soon :(
chipotle_coyote 8y ago
I admit I'm hoping (although not remotely expecting) that now that Spectrum is part of the GitHub/Microsoft nexus, they'll contribute some development time to getting RethinkDB going again, even if it requires another fork -- there was a brief "RebirthDB" fork that was, theoretically, going to become the official release, but that seems to have stalled, too. The 2.4 release has been "nearly ready" for over two years now, and I'm kind of afraid that the lost momentum will be unrecoverable very soon, assuming we're not already past that point.
andy_ppp 8y ago
Making mistakes means the author delivered a lot of features to users that they wouldn’t have otherwise. RethinkDB sounds terrifying though, I’d hate for my DB errors in production to literally have no idea what to do, it makes me feel sick thinking about :-) I think we should aim for kludgy but boring working solutions first - for example I’m tempted to write a redux middleware that sends dispatched actions to the server and manually sync, order and manage conflicts in these events to build a “perfect” system where front end state management and backend CQRS perfectly marry up. It’s a terrible idea because I know how to build the Podcast app I’m making perfectly well without any of this nonsense.
- arvinsim 8y ago
  > front end state management and backend CQRS perfectly marry up. I am currently researching how to do this properly. What would you think would be the "boring but reliable" way to do it?
  - andy_ppp 8y ago
    Well I want to do this but the point is I think it's research and unknown; I'm actually saying don't do this! Have an endpoint and call it for changes. No stream of events perfectly queued and ordered between systems. Just accept your app won't be as clever and well designed but it might actually just work :-)
- threeseed 8y ago
  > I think we should aim for kludgy but boring working solutions first Nice idea in theory. Can be awful in practice. For example in enterprises it's very common to see applications last years or even decades. And so that kludgy but boring solution would be the foundation on which you will have hundreds of engineers and years of work built on top of. And because your kludgy but boring solution worked in the beginning you rarely go back and redo it. Hence why you see a lot of upfront developers built these over-architected monstrosities. It's because they are trying to cater for a decade of possible new features.
  - 8y ago
stickfigure 8y ago
A great mobile experience on desktop is bearable and only needs tweaking to work well. That depends on your product and your audience! Many (probably most) B2B apps work poorly in the constraints of mobile. If your users spend their 9-5 hours buried in your app at the office, they probably value things like hotkeys, multicolumn layouts, and high-information-density pages.
- mxstbr 8y ago
  That is a great point, thanks for making it. You are absolutely right, I was overgeneralising with that lesson!
- uxcolumbo 8y ago
  Great point and I can confirm this. Working on enterprise apps in the past and seeing design teams choosing something like Material Design for those web apps, even though it's not suitable for those apps, especially because the information density is poor when using MD.
lxe 8y ago
Regrets: not using cool new frontend things while using cool new backend thing.
- k__ 8y ago
  It's just a question of risk assessment. Will the new tech give you leverage over companies who don't use it or will it be discontinued and leave you with unmaintained crap? Will the old tech give you a stable base to build upon or will people with new tech overtake you with less effort? etc.
Tehchops 8y ago
Seems like some pretty domain-specific(frontend)choices about which $jsThing to use, and one pretty bad operational miss on choosing a DB tech correctly.
quickthrower2 8y ago
RethinkDB, an ironic name in this context.
- smacktoward 8y ago
  At least you can't say they didn't warn you!
ppeetteerr 8y ago
Not using something seems like a hard case to make. The author doesn't know what would have happened had he used another tool. However, I do believe it's possible to properly evaluate a tool after having used it, so... 2/4?
shay_ker 8y ago
I ran into similar issues with Draft.js, but Trix has been amazing: https://github.com/basecamp/trix https://github.com/basecamp/trix It's not that hard to wrap it as a React component and get going with it
- mr_toad 8y ago
  I would have gone with markdown and/or some other markup language. It’s so much easier to leaverage other tooling (e.g Git), when your source text is a widely used text format.
  - shay_ker 8y ago
    Definitely. Our users aren't as tech-savvy, so we wanted to have some basic WYSIWYG functionality instead of educating them on markdown.
dirtylowprofile 8y ago
Seems like bad choices and lack of research.
skywhopper 8y ago
I feel like they missed a couple of critical takeaways: First, build on technologies you already understand, if possible. Don't build from scratch on something you know nothing about. And second, make sure you have some backend expertise on your team. He says up-front the three person team was heavy on design and front-end expertise. So it's not surprising at all to me that they had big problems managing and troubleshooting their poorly chosen backend tech.
walrus01 8y ago
The name "Spectrum" has regrettably been ruined by Charter, which has the same poor and indifferent customer service for last mile cable internet customers as other competing giants like Comcast.
mxxx 8y ago
Kind of impressive that they built Spectrum with just three people. Nice write up.
nstart 8y ago
This is tangential/possibly off-topic. I was wondering if anyone could educate me as to why this site needs to use next.js in the first place (the site of the blog, not spectrum). It's mentioned in this blog post and I followed the link. The full tech stack is given here -> https://github.com/mxstbr/mxstbr.com#tech-stack https://github.com/mxstbr/mxstbr.com#tech-stack I went through the codebase, and the content itself is static. I'm not attempting to bash the decision to use next at all. I'm only looking to grow my understanding of the usage of next since I see it being mentioned a lot. The question I have is, why use next/react for what appears to be a static site. Or, why not use static html + markdown? Again, not bashing. Just looking for reasons that I might have missed due to my lack of understanding/context.
- sisk 8y ago
  Same reason why some folks like Gatsby. Navigate around his site and you'll see it loads in very quickly and with push state instead of full reloads. It's been done many times over for every stack and client side tool (pJax!) but that includes the next.js router.
  - ousta 8y ago
    yeah you can do that with html and javascript since the 90s
    - Vinnl 8y ago
      Having built my blog with React Static, I can tell you that this is far easier and fool-proof to do than it is using HTML and Javascript. It might sound like introducing a tool is overcomplicating things, but in this case, it really is simpler. (Not sure if this holds for Next.js as well, since I believe it does a few other things too, but React Static has been a breeze for me.)
  - jefftk 8y ago
    It's fast, but for a simple site like this I suspect plain HTML + cacheable CSS would be just as fast.
fourstar 8y ago
What would you replace Draft.js with? Slate?
- wes-k 8y ago
  We went with ProseMirror for https://wikiful.com https://wikiful.com. It's probably the most powerful but is also not a plug-and-play setup and required a handful of tweaks. If I wanted a lighter solution, I'd probably give https://trix-editor.org/ https://trix-editor.org/ (made by basecamp) a try.
dlevine 8y ago
I think that the most important line in this article is "Changing these decisions would not have made Spectrum a better product by itself." Assuming that you make somewhat reasonable choices in the first place, technology likely won't become a problem for quite a while. At which point you either have succeeded enough to have the resources to fix the issues that come up, or else you have bigger problems than technology and should focus on those instead.
- speby 8y ago
  I really love that you pointed this out. This is why things like getting wrapped around the axle deciding between React or Angular for your next project and "which is better?" type of decision-making frameworks that engineers often get stuck in miss the point. More often than we can appreciate, pick something, anything (!), and move forward.
honkycat 8y ago
Rethinkdb was complete trash. A bane to run and pathetic at scaling. Small backups took hours. It was extremely difficult to tune.
- habitue 8y ago
  A bane to run? Like what happened when you ran it?
  - deleted 8y ago
    [deleted]
  - honkycat 8y ago
    Constant slowness and down times. Bad logging that did not provide enough information. Database backups would take an ETERNITY to dump, and even longer to restore. We once had a 5 machine cluster. We decided we needed to re-balance the cluster. The thing COMPLETELY CRASHED and went up in flames, caused us to have to stay up all night fixing it. It was the same day we decided to rewrite our application to not use rethinkdb. Best decision we could have made.
pjmlp 8y ago
Interesting read, as always the business value is the one that should be assessed for technology adoption, not coolness factor.
Annatar 8y ago
Summary: "computers are hard, getting the software written correctly even harder". Yeah, that's right! If you're struggling with this, it time to seriously consider another profession. Barrier to entry being low is really misleading. It never was low and because of how generic and complex computer systems are, it isn't low now. It will only get more complex as time goes on, unless everybody pulls together and fights tooth and nail to go back to writing small, fast software. Anybody considering "I just want to program and not worry about low level details! Which framework can I use?" should stop dead in their tracks and seriously consider what they are doing with their life.
matte_black 8y ago
Way too many developers are shocked to learn that Postgres has an existing Pub/Sub system using LISTEN and NOTIFY. Kind of makes some people rethink their stack.
owaislone 8y ago
RethinkDB was so promising and still is in a way. It just didn't take off as an open source, openly government project (yet). It's still early though. I hope it forms a great community around itself and becomes a major open-source database offering. Apache or CNCF adopting it wouldn't be the worse thing ever even though not a super CNCF like product.
wavicle 8y ago
I created a public community for Hacker News itself: https://spectrum.chat/hackernews https://spectrum.chat/hackernews Something that I have always disliked about HN is the lack of the ability to delete comments and accounts. OTOH, Slack etc are private and lock up good content/discourse away from search engines. Hopefully, spectrum will offer a better balance.
aboutruby 8y ago
The examples are quite interesting but the insights / conclusions are far too simplistic and overreaching

309 points by theBashShell 8y ago

andonisus 8y ago

Was using node over another language/ecosystem a baked-in requirement?

mhd 8y ago
A chat application is to node.js what a blog was to Ruby on Rails or PHP -- it's basically the default example of every framework and library. Low complexity, high throughput. So you'd have no trouble finding good examples and libraries. For a while, Erlang was quite popular in that area, but as some orgs only used it for that and thus didn't get too deep in the tech stack, they were eager to switch to something they imagine they know a bit better.
- k__ 8y ago
  Erlang had the problem that it got more popular at the same time as the rise of Go happened, which also played the back-end-concurrency game.
mxstbr 8y ago
The only programming language we all know is JavaScript, so it was not an option to go with another backend language. I would love to learn Elixir though, from what I have heard it is great for real-time!

catears 8y ago

I am right now on the train home from work quite late (22:40 local time). The reason I spent so long at work today is because we update after 8 o'clock. However, we found a critical bug in some open software that we use that we do not know why it triggers. We barely even know how it happens! Of course we haven't been able to solve it yet... After personally spending a lot of time with trying to fix the software I can say that I have gotten a much deeper appreciation of tools that are widely used and with an active community, where most bugs have already been solved. Previously I had believed if you had a tool that solved the exact problems you have, then you should use it. I hope I'll resist such an urge in the future by having a little pragmatic angel on my shoulder reminding me of the danger of underused software. No software is perfect and even tough you might be able to fix software when it is open source, you paint yourself into a corner when you will necessarily have to fix it. I felt my experience was matching some of the authors woes and I urge anyone that chooses technologies to think one step ahead and learn from our mistakes!

quickthrower2 8y ago
To avoid burning out I suggest: 1. Deploy 2. Test deployment 3. If success, great go home at 8:10pm. 4. If fail, rollback, retest, go home at 8:20pm. Come in next day and fix in source code and schedule new deployment. 5. To avoid #4 in 99% of scenarios, use a staging environment.
- opportune 8y ago
  In my experience staging environments only work in a few (very common) use cases. When I do big data work I certainly use a test environment but we can't just replicate all the data in two clusters because that would be absurdly expensive - and this makes testing performance basically only possible in prod. I'm sure basically any database system with a non-trivial amount of data has the exact same issue. But staging definitely works for something like a web server
- catears 8y ago
  Luckily we have "update nights" at most once every other month. But the workflow you describe is what I would want in the end. I work in a small startup tough so change is happening rapidly to make these processes better. It's far from institutionalized! We do however have a staging environment already that is frequently updated and updates available within an hour from starting the update. Thanks for the concern and tips nonetheless!

jessaustin 8y ago

Some of these seem difficult to predict. If you knew in advance that Github would acquire, WYSIWYG over markdown wouldn't have been a priority. You couldn't have known that, however. Developers know markdown, web creatives know markdown, but does anyone else?

mr_toad 8y ago
> Developers know markdown, web creatives know markdown, but does anyone else? Randoms who comment on Reddit. It’s not a high bar. I actually prefer using markdown than fighting with an opinionated WYSIWYG editor. (Looking at you Word).
mxstbr 8y ago
You are inverting the reasoning. GitHub bought us because our main audience is developers. We should have stuck with markdown, because our main audience is developers, not because GitHub also saw that and acquired the company.

TimTheTinker 8y ago

I clicked on this hoping this was the "Spectrum" cable ISP. We don't hear too often from ISPs and infrastructure companies on HN.

teej 8y ago
There’s also an AWS offering called Spectrum and a data enrichment platform called Spectrum. Pretty overloaded name.
- acemarke 8y ago
  Not as bad as "Jetpack" :) https://news.ycombinator.com/item?id=18819708 https://news.ycombinator.com/item?id=18819708
- Junk_Collector 8y ago
  There's also an engineering trade magazine called Spectrum. It's everywhere.
  - 4thaccount 8y ago
    IEEE Spectrum has been around for a long time and is one of the reasons I became an engineer. I can still remember tearing into the article on the DARPA Autonomous Robot challenge.
- nineteen999 8y ago
  You could monitor your AWS Spectrum and data enrichment Spectrum with Spectrum by CA Technologies.
AnaniasAnanas 8y ago
Thought that it was about ZX Spectrum by Sinclair.
- IggleSniggle 8y ago
  And here I thought it was about a technologist working at the vitamin company, Spectrum.

kodablah 8y ago

On the side I'm building a communication app myself and I've started over a few times now. I made some mistakes in early development that caused starting over to be the best choice (I'm not a perennial start-over guy, things weren't very far along when I restarted, this is just a side thing). Mistakes: I did plenty of backend work (e.g. gRPC services) just to realize it didn't mesh well with the frontend when I started to build it. I over-complicated the feature set and realized I built a foundation for an MVP that would take forever. I abstracted everything because in my head I thought about all the future uses. I worked on an advanced-tech frontend that kept me bogged down in frontend development instead of doing the whole thing. All of these are typical mistakes of pie-in-the-sky side projects sans deadlines. For the latest iteration I have changed my approach. I am building the dumbest web UI w/ the dumbest in-memory-only-at-first backend with minimal abstractions. The initial web UI doesn't even use any JS which I know can seem like extra work w/ HTML forms and the like, but the raw simplicity is easier to build now and take away later than something more complex. I'm deferring lots of features. Once I reach a web-UI-only MVP, my next step will be to abstract what already isn't on the UI front and make a Qt app that uses the same abstraction. I've found this to be the easiest way to get some UI idea reuse across different paradigms. I can add more UIs including an API, terminal, mobile, etc with this approach. For the backend, simple gRPC backed by a "db" of in-memory data structures for now until I abstract that to allow sqlite to join and then on from there. It is very refreshing to develop a full-stack app without a complex full stack. The major benefit of developing a stupid-web-with-in-memory-db MVP? Testing and quick iteration. I've found you can iterate on core structures/ideas or you can iterate on external tech/features, but you can't do both at the same time.

saagarjha 8y ago

> We are building native apps now, but starting from scratch is time consuming. If we had used react-native-web to build the website, we could have reused the base components and built the native apps much faster! > Optimize for iteration speed and flexibility. Faster, but not necessarily better. Reusing web technologies for mobile is almost always an optimization for developer time, which might work early but I feel almost always ends up needing to be rethought in the future.

rhizome 8y ago
The phrase "optimize for iteration" feels like something you do when you don't know what you're doing. They say experienced developers spend most of their time thinking, vs. writing code, and so with inexperience you don't have the tools to eliminate iterations in your head.
- nostrademons 8y ago
  In a startup, by definition you don't know what you're doing. Once you know what you're doing, it's not a startup, it's an established business. Once everybody knows what you're doing, it's called an industry. It's usually fruitless for a startup to chase after problems that everybody knows how to solve, because somebody has already solved them, probably better than a small team of junior developers can. Experienced developers spend most of their time thinking because experienced developers tend to work in fields where at least the problems are known, as well as some best practices for solutions. That's how they got to be experienced, after all. But this is also why experienced developers, when they choose to found startups, often end up with B2B startups that slot into an existing industry structure, not startups that end up defining the industry. (Source: experienced developer now founding a startup and wrestling with just how little all that experience matters when it's not even clear what problems will dominate the industry or if the industry will even come to exist.)
  - saagarjha 8y ago
    The tools for making a mobile application is something that I consider to be "solved", except in some very specific cases. If you are a startup, you are likely innovating in something that is not making apps, so I do not agree that you "don't know what you're doing" in this area.

stockkid 8y ago

It seems contradictory to me that author learned to "deliberately assess cutting edge technologies, bias towards conservative choices," yet he regrets not using react-native-web and Next.js.

j2kun 8y ago
Wait until the author hears about react-native-web-native, the go-to solution for using your react-native-web components in a native environment!
- sephoric 8y ago
  I honestly can't tell from your comment if that really exists or is satire.
  - kbenson 8y ago
    Neither can I. I'm I'm leaning towards it existing but being used as a vehicle of satire, because that's just how crazy the world is now.
    - navs 8y ago
      https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web
      - stronglikedan 8y ago
        I don't know why I find it so funny that the browser's back button doesn't work in the examples[0]. [0] https://necolas.github.io/react-native-web/examples/ https://necolas.github.io/react-native-web/examples/
        ollerac 8y ago
        Because re-implementing native browser features that are core to an application's usability is a hard problem that "cutting edge" web frameworks open you up to?

k__ 8y ago

I worked at a startup that used RethinkDB too. Change feeds sounded cool, but we never used them in the end, because of the latency. I didn't use react-native-web, because back in the days it was alpha and later there was react-native-dom, which seemed like a better approach, but I have the feeling it doesn't have much pace to get anywhere any time soon :(

chipotle_coyote 8y ago

I admit I'm hoping (although not remotely expecting) that now that Spectrum is part of the GitHub/Microsoft nexus, they'll contribute some development time to getting RethinkDB going again, even if it requires another fork -- there was a brief "RebirthDB" fork that was, theoretically, going to become the official release, but that seems to have stalled, too. The 2.4 release has been "nearly ready" for over two years now, and I'm kind of afraid that the lost momentum will be unrecoverable very soon, assuming we're not already past that point.

andy_ppp 8y ago

Making mistakes means the author delivered a lot of features to users that they wouldn’t have otherwise. RethinkDB sounds terrifying though, I’d hate for my DB errors in production to literally have no idea what to do, it makes me feel sick thinking about :-) I think we should aim for kludgy but boring working solutions first - for example I’m tempted to write a redux middleware that sends dispatched actions to the server and manually sync, order and manage conflicts in these events to build a “perfect” system where front end state management and backend CQRS perfectly marry up. It’s a terrible idea because I know how to build the Podcast app I’m making perfectly well without any of this nonsense.

arvinsim 8y ago
> front end state management and backend CQRS perfectly marry up. I am currently researching how to do this properly. What would you think would be the "boring but reliable" way to do it?
- andy_ppp 8y ago
  Well I want to do this but the point is I think it's research and unknown; I'm actually saying don't do this! Have an endpoint and call it for changes. No stream of events perfectly queued and ordered between systems. Just accept your app won't be as clever and well designed but it might actually just work :-)
threeseed 8y ago
> I think we should aim for kludgy but boring working solutions first Nice idea in theory. Can be awful in practice. For example in enterprises it's very common to see applications last years or even decades. And so that kludgy but boring solution would be the foundation on which you will have hundreds of engineers and years of work built on top of. And because your kludgy but boring solution worked in the beginning you rarely go back and redo it. Hence why you see a lot of upfront developers built these over-architected monstrosities. It's because they are trying to cater for a decade of possible new features.
- 8y ago

stickfigure 8y ago

A great mobile experience on desktop is bearable and only needs tweaking to work well. That depends on your product and your audience! Many (probably most) B2B apps work poorly in the constraints of mobile. If your users spend their 9-5 hours buried in your app at the office, they probably value things like hotkeys, multicolumn layouts, and high-information-density pages.

mxstbr 8y ago
That is a great point, thanks for making it. You are absolutely right, I was overgeneralising with that lesson!
uxcolumbo 8y ago
Great point and I can confirm this. Working on enterprise apps in the past and seeing design teams choosing something like Material Design for those web apps, even though it's not suitable for those apps, especially because the information density is poor when using MD.

lxe 8y ago

Regrets: not using cool new frontend things while using cool new backend thing.

k__ 8y ago
It's just a question of risk assessment. Will the new tech give you leverage over companies who don't use it or will it be discontinued and leave you with unmaintained crap? Will the old tech give you a stable base to build upon or will people with new tech overtake you with less effort? etc.

Tehchops 8y ago

Seems like some pretty domain-specific(frontend)choices about which $jsThing to use, and one pretty bad operational miss on choosing a DB tech correctly.

quickthrower2 8y ago

RethinkDB, an ironic name in this context.

smacktoward 8y ago
At least you can't say they didn't warn you!

ppeetteerr 8y ago

Not using something seems like a hard case to make. The author doesn't know what would have happened had he used another tool. However, I do believe it's possible to properly evaluate a tool after having used it, so... 2/4?

shay_ker 8y ago

I ran into similar issues with Draft.js, but Trix has been amazing: https://github.com/basecamp/trix https://github.com/basecamp/trix It's not that hard to wrap it as a React component and get going with it

mr_toad 8y ago
I would have gone with markdown and/or some other markup language. It’s so much easier to leaverage other tooling (e.g Git), when your source text is a widely used text format.
- shay_ker 8y ago
  Definitely. Our users aren't as tech-savvy, so we wanted to have some basic WYSIWYG functionality instead of educating them on markdown.

dirtylowprofile 8y ago

Seems like bad choices and lack of research.

skywhopper 8y ago

I feel like they missed a couple of critical takeaways: First, build on technologies you already understand, if possible. Don't build from scratch on something you know nothing about. And second, make sure you have some backend expertise on your team. He says up-front the three person team was heavy on design and front-end expertise. So it's not surprising at all to me that they had big problems managing and troubleshooting their poorly chosen backend tech.

walrus01 8y ago

The name "Spectrum" has regrettably been ruined by Charter, which has the same poor and indifferent customer service for last mile cable internet customers as other competing giants like Comcast.

mxxx 8y ago

Kind of impressive that they built Spectrum with just three people. Nice write up.

nstart 8y ago

This is tangential/possibly off-topic. I was wondering if anyone could educate me as to why this site needs to use next.js in the first place (the site of the blog, not spectrum). It's mentioned in this blog post and I followed the link. The full tech stack is given here -> https://github.com/mxstbr/mxstbr.com#tech-stack https://github.com/mxstbr/mxstbr.com#tech-stack I went through the codebase, and the content itself is static. I'm not attempting to bash the decision to use next at all. I'm only looking to grow my understanding of the usage of next since I see it being mentioned a lot. The question I have is, why use next/react for what appears to be a static site. Or, why not use static html + markdown? Again, not bashing. Just looking for reasons that I might have missed due to my lack of understanding/context.

sisk 8y ago
Same reason why some folks like Gatsby. Navigate around his site and you'll see it loads in very quickly and with push state instead of full reloads. It's been done many times over for every stack and client side tool (pJax!) but that includes the next.js router.
- ousta 8y ago
  yeah you can do that with html and javascript since the 90s
  - Vinnl 8y ago
    Having built my blog with React Static, I can tell you that this is far easier and fool-proof to do than it is using HTML and Javascript. It might sound like introducing a tool is overcomplicating things, but in this case, it really is simpler. (Not sure if this holds for Next.js as well, since I believe it does a few other things too, but React Static has been a breeze for me.)
- jefftk 8y ago
  It's fast, but for a simple site like this I suspect plain HTML + cacheable CSS would be just as fast.

fourstar 8y ago

What would you replace Draft.js with? Slate?

wes-k 8y ago
We went with ProseMirror for https://wikiful.com https://wikiful.com. It's probably the most powerful but is also not a plug-and-play setup and required a handful of tweaks. If I wanted a lighter solution, I'd probably give https://trix-editor.org/ https://trix-editor.org/ (made by basecamp) a try.

dlevine 8y ago

I think that the most important line in this article is "Changing these decisions would not have made Spectrum a better product by itself." Assuming that you make somewhat reasonable choices in the first place, technology likely won't become a problem for quite a while. At which point you either have succeeded enough to have the resources to fix the issues that come up, or else you have bigger problems than technology and should focus on those instead.

speby 8y ago
I really love that you pointed this out. This is why things like getting wrapped around the axle deciding between React or Angular for your next project and "which is better?" type of decision-making frameworks that engineers often get stuck in miss the point. More often than we can appreciate, pick something, anything (!), and move forward.

honkycat 8y ago

Rethinkdb was complete trash. A bane to run and pathetic at scaling. Small backups took hours. It was extremely difficult to tune.

habitue 8y ago
A bane to run? Like what happened when you ran it?
- deleted 8y ago
  [deleted]
- honkycat 8y ago
  Constant slowness and down times. Bad logging that did not provide enough information. Database backups would take an ETERNITY to dump, and even longer to restore. We once had a 5 machine cluster. We decided we needed to re-balance the cluster. The thing COMPLETELY CRASHED and went up in flames, caused us to have to stay up all night fixing it. It was the same day we decided to rewrite our application to not use rethinkdb. Best decision we could have made.

pjmlp 8y ago

Interesting read, as always the business value is the one that should be assessed for technology adoption, not coolness factor.

Annatar 8y ago

Summary: "computers are hard, getting the software written correctly even harder". Yeah, that's right! If you're struggling with this, it time to seriously consider another profession. Barrier to entry being low is really misleading. It never was low and because of how generic and complex computer systems are, it isn't low now. It will only get more complex as time goes on, unless everybody pulls together and fights tooth and nail to go back to writing small, fast software. Anybody considering "I just want to program and not worry about low level details! Which framework can I use?" should stop dead in their tracks and seriously consider what they are doing with their life.

matte_black 8y ago

Way too many developers are shocked to learn that Postgres has an existing Pub/Sub system using LISTEN and NOTIFY. Kind of makes some people rethink their stack.

owaislone 8y ago

RethinkDB was so promising and still is in a way. It just didn't take off as an open source, openly government project (yet). It's still early though. I hope it forms a great community around itself and becomes a major open-source database offering. Apache or CNCF adopting it wouldn't be the worse thing ever even though not a super CNCF like product.

wavicle 8y ago

I created a public community for Hacker News itself: https://spectrum.chat/hackernews https://spectrum.chat/hackernews Something that I have always disliked about HN is the lack of the ability to delete comments and accounts. OTOH, Slack etc are private and lock up good content/discourse away from search engines. Hopefully, spectrum will offer a better balance.

aboutruby 8y ago

The examples are quite interesting but the insights / conclusions are far too simplistic and overreaching