Comments URL: https://news.ycombinator.com/item?id=33628156

Points: 3

# Comments: 0

[0] https://twitter.com/notesnook/status/1591048432931975168 [1] https://twitter.com/notesnook/status/1588602471290572800

Have you given Notesnook a try? While it doesn't have multi window support they have it on their roadmap: https://notesnook.com/roadmap

Do I feel sorry for the people who got layed off? Of course I do! I wouldn't want to be them right now. I feel for them. But the consequences mentioned in this post is completely unreasonable. These are the kinds of points you hear from a depressed person who thinks the world is going to end because all the toilet rolls are suddenly out of stock.

The amount of doomsaying I see everywhere regarding the Musk takeover is baffling. I am no Musk fanboy but this is completely irrational. The fact of the matter is, people don't like change. That's all there is to it. Change automatically makes people cry out.

Here's a scenario for you:

What if the new Twitter is better? What if it isn't the toxic place you expect it to become? What if you are completely wrong? Have you considered that? Here's how I see this situation:

Musk is not an idiot. He must know exactly what he needs to do. This isn't his first rodeo and comments like "running a service of this scale and size is incredibly complex with downtime and uptime and blah blah" is incredibly naive. Musk runs at least 2 companies that require a huge network & availability guarantees. He knows what's needed there.

Twitter is going no where and if you think it'll go down in the coming years, you have a surprise coming your way. I am optimistic because of Musk isn't known to give up. This can fail for sure but I don't think that'll be the end of it.

The next step in my opinion is cutting down on the Twitter codebase. Trimming features. Shutting down unnecessary stuff. They laid off 25% of the workforce so at least 25% of Twitter will be affected. Let's see which parts though. There's a lot of unnecessary junk in there (communities, spaces etc.) that I'll be happy to say goodbye to.

And yes, Babel can also be made faster if enough effort is dedicated into it. it's not an impossible feat.

Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as it is being spent to rewrite it in Rust, I have no doubt that it can become faster. Perhaps it'll require some big changes but it won't create compatibility concerns and it won't be a cat-and-mouse race between the Rust version and the TS version.

I don't think "Write it in Rust" is always the solution to fast programs. Rust itself can be pretty damn slow if you don't keep performance in mind. That is why you have to optimize and profile and optimize over and over again. Can't the same be done for TSC?

I think the biggest reason devs don't do this is because no one likes profiling and optimizing since it is a slow and boring task. Rewriting is so exciting! It's the thing you do when you are tired of maintaining the old codebase. So just ditch it and rewrite it in Rust.

I have nothing against Rust, mind you. I love what it has done but I don't think rewriting everything is either feasible or even the solution. And waiting for that to happen for every slow tool out there is utter foolishness.

So I have been playing around with Dart and while it seems cool as a language the tooling performance is absolutely abysmal. As the title says, dart --help takes 500ms just to print the help. I tested it out on Intel & AMD (as if it's such a complex task).

In any case, I also posted an issue in the repo but it was closed with a very vague "it needs to run a bunch of Dart code to print help message and that takes time". [0]

Can someone with more experience in this language explain what I am doing wrong? In comparison, node --help takes 51ms.

I don't think it's such a straining task for it to take this long. Consequently, dart format is also similarly slow taking 300ms to format a file with 3 lines.

The thing I am asking is, is it just me or this is the new norm?

Links in comment.

Comments URL: https://news.ycombinator.com/item?id=33434303

Points: 1

# Comments: 2

Using Tesla engineers is just to get everyone talking. I don't think they can get a clear picture by looking at last 30 days of code but they can use this as reason to lay a lot of people off. Not that Musk needs reasons, obviously.

In my mind I think Twitter is going to go on a very, very different direction than we all expect. You have to understand that Musk isn't after the big dollar here but rather he is experimenting which has a lot of chances to fail. Twitter could become extraordinary or it could become utter trash, we'll have to wait and see. Personally, I am quite excited to see where this goes.

Building the next unicorn is awesome and all but in my opinion, this has it's own place. I am glad some people out there get to work on their dream projects and actually can make a living out it. Kudos to all the supporters, obviously.

I also love how focused SerenityOS is and what kind of audience it caters to. Some people might say, "make it for everyone" but that doesn't work most of the time. Having a focused audience allows a lot of freedom in the way of UX/DX, docs, communication etc. So I am glad Andreas set that down upfront.

Saying that Markdown is bad is really naive. There are not many ways to specify formatting without it getting in the way of your writing. Markdown is popular because it strikes the right balance where reading a markdown document requires a lot less visual strain compared to the same HTML document. It requires the least amount of letters to specify formatting - italics is 2 chars, bold is 4 chars, underline is 2 chars etc. Lists are mostly inferred and require no additional formatting. Compare that to HTML which requires 5+n chars (where n is the number of chars in the tag name) regardless of which format you want to use.

Markdown does have it's quirks but they don't come up 99% of the time unless finding them is specifically your intention. Knowing whether *__hello__* is bold italic or italic bold is not important unless you are writing a parser.

The downsides of Markdown are much, much less than the downsides of HTML. Writing is not the same as designing a website or a UI. It's not meant to be pretty and typesetting + styling should not be the concern of writers.

Comments URL: https://news.ycombinator.com/item?id=33277064

Points: 4

# Comments: 0

Can you tell me why the above wouldn't work and why this is better?

I know GitBook exists but it's not OSS and is fairly complex on its own: a whole platform with its own learning curve.

I am looking for something that can:

- generate documentation from markdown - minimal but modern design (doesn't have to be configurable) - zero setup/dependencies i.e. plug'n'play

Here's the workflow I am looking for:

- clone

- install xyz for platform

- make edits

- xyz dev/start

I have explored Hugo and Zola but I don't like the multiple directories they create for themes, CSS, js etc. I want the generator to be self-contained.

The reason I am here asking is if someone has a personal project that does something like this that they'd like to share. Or if someone is working on something similar and would like users.

Comments URL: https://news.ycombinator.com/item?id=33097625

Points: 6

# Comments: 4

Points: 1

# Comments: 0

Obviously, that isn't always possible. I find this approach especially useful in writing e2e browser tests. You write an abstraction over the testing framework's (playwright, puppeteer etc) interaction and then use that in your tests.

So instead of writing:

    await page.click(".play-button");

    await app.play();

- Managing users (user data is spread across multiple services/db so JS works very well here)

- SaaS analytics (total users, monthly users, subscriptions etc. For this AppSmith's charts "just worked" along with full support for MongoDB query language).

- Managing small internal tools (sending emails to users via GUI etc.)

I haven't tried some of the new stuff you guys have shipped yet (the new table, some light customization etc.). The whole reason behind choosing something like AppSmith was that I will only have to be concerned about data. No fuss about UI. No manual styling. No tinkering. For this AppSmith is perfect.

Along this line, I think what would be absolutely amazing is something like themes. They should be separate (think like editor themes). Theme designers can design how the widgets will look. Builders will focus on what they want to build. Instead of adding multitudes of controls and customizability in the widget view, this would be a better approach imo since I'd never be able to customize everything consistently which would result in a really broken UI.

Aside from that, AppSmith is great. Oh another thing that really frustrated me was the small inline editor for events/callbacks. It'd be super helpful to allow maximizing it somehow. Another thing in the same line is allowing importing modules. So for example, I can use AppSmith's minimal SDK to code my logic in TS using VSCode and then import that into AppSmith and it just works. It'd also allow using JS-only libraries from npm etc. This is definitely not as simple as it sounds but you get the idea.

- Open source

- Self hosted

- VCS integration via git

- Lots of widgets

- Support for custom JS anywhere

- UI is okayish (for internal apps)

If this was open source & self host able then maybe but as it stands, there's no point. AppSmith has been the only low-code tool that allowed me to build exactly what I wanted thanks to their JS support. Budibase etc all lack that and fail miserably outside of a few standard cases.