Comment by chaos_emergent | Hacker News Reader

Comment by chaos_emergent | Hacker News Reader

Sounds like you're in a similar place as me a year ago. Here's a list of tools that I'd use:

- TypeScript for language. Gives you an insanely expressive type system that is a step up from Python duck typing (which you seem familiar with after perusing your GH).

- React for framework. Frontend experts will shit on it for being non-performant or having a poor UX, but the community is massive and you'll have a ton of support both in terms of people that can help you when you're stuck and libraries that do a lot of work for you.

- Jest for code testing and Cypress for integration testing. The obvious tools for the job.

- Chakra UI for a UI framework. Has all the bells and whistles, DX is great, and there are plenty of escape hatches for non-default behavior.

- TipTap for text editor. This is the _most_ at risk of not being supported in 10 years, but I still see it as a low risk because they have a solid monetization strategy in place.

- Electron for the desktop app. If you _really_ don't want to use Electron then use Tauri (what we use at my company). It uses the native browser engine so package sizes are ridiculously small and it's insanely performant.

- Don't worry about the mobile apps for now. At the very most, just make it a web app that has responsive theming for mobile.

Good luck and have fun!

I have to disagree with the Typescript part. Granted, it's not a bad suggestion, and there's a lot that's good about TS, but this isn't what I would consider a good place for it for a few reasons.

TS, in my experience, has limited benefit when it comes to building a UI, and frontend JS is heavily married to UI programming. For guaranteeing UI functionality, writing years is a better use of one's time. What's more important with UI development is the ability to change visual components fast, and TS often gets in the way of that because it's strict as a feature.

Someone who is deep into TS may have the experience such that they are an exception, and can really benefit from using TS across the board. Since the OP is asking for a frontend framework, I would not assume they are one of these exceptions.

Where TS really shines, IMO, is in business logic and library code, because that's where concrete expectations and promises typically lie. TS is also really good for writing backends for similar reasons.

This might be most appropriate for the OP:

Frontend: Some TS for logic that's well separated from the UI, but don't try to make TS work within code that is rendering stuff. Major frameworks put in lots of effort to support TS in the view layer and, with some exceptions, it usually comes with caveats

Tests: Use JS. Your tests should not be an app in and of itself.

Shared libraries: Use TS only if you prefer it or if other entities are using it, in which case TS helps your code fulfill it's promise to third parties.

And if the OP really ends up hating Typescript, then they should just not use it. TS is not a requirement.

don't try to make TS work within code that is rendering stuff. Major frameworks put in lots of effort to support TS in the view layer and, with some exceptions, it usually comes with caveats

I’m really not sure what problems you have in mind here. I’ve found TS to be really useful with very few caveats.

The biggest problem you’re likely to hit in TS is when things subtly lose their strong typing accidentally -- for example, you need to use some API that works with untyped JSON blobs. But the you’re no worse off than if you were just using plain JS in the first place.

TS is especially great when you’re using libraries with good type annotations -- your IDE can give you useful live typechecking and autocompletion, even if your own code is in JS!

In React code, TS is really good because you can statically check your prop types. There is a little bit of a learning curve to doing that both correctly and tersely, but I think it’s more than worth the effort.

As the OP specifically said they wanted strong typing, TS seems like an obvious choice over vanilla JS. I suppose you could consider other things like Flow or Reason, but TS is the most widely-used by far.

OP literally mentions that weak typing is a deal breaker, so they should definitely use typescript.

Honestly, I did not catch that part. I still think it's a poor idea, but that's only my opinion. If they really don't want weak typing, then yeah, TS it is.

For personal projects you should learn how to make TS shut up. I’ve found TS useless on the front end for many places… but for state and utility libraries it’s nice. Hence don’t aim for complete strictness.

That's a good point. TS is still very helpful for catching things before build time, but I don't always want it to actually stop me from doing certain things (which I know can be overridden but that takes more actions).

Sorry, I have to disagree. I used React before with JS and moved to TS, and the difference is just night and day. Forgot a prop? Wrong parameters in a function? Forgot to import a component? TS catches all these while JS doesn't.

What problems specifically do you have with TS on the frontend?

Spot on. 3 years ago I threw a huge tantrum and almost quit my job because they forced us to use TS. Today, I would never code for more than myself without TS. I see it really as more of a "contract system" than a "type system" and that's the real subtle genius of it.

There is not reason whatsoever to use JS over TS for UI. None of the things you said are true.

I agree with you - with the premise of many years of development JS is a much better fit for manipulating the DOM. ClojureScript also accomplishes an isomorphism with what it represents under the hood while being dynamically typed and it seems like people enjoy that DX too.

For a beginner, my experience is that TS is a good way of discovering and working with the complexity and feature set of HTML and web browsers.

IMO if you are using React, you absolutely should be using Typescript for UI on non-legacy codebases. There is most certainly a learning curve in understanding why Typescript seems to show you errors in your UI code, but once you understand the ~5 most common errors it becomes much, much easier to use Typescript instead of JS. I simply won’t use React components (or other libraries for that matter) from NPM if they don’t have Typescript typings (or if I can’t easily create an abstracted shim over the untyped code).

The benefits to using Typescript are immense.

Strongly disagree. TS is very useful for UI, among other things, especially for lots of throw-away or prototype code that changes fast quite often. TS makes it really painless to move and change things around, as opposed to plain JS where things will break quite often on runtime.

Concur with these suggestions.

TypeScript + React + a good UI library like Chakra will do most of the legwork for you.

For anything where you need to reach into the HTML/JS/CSS, find the right place in the React lifecycle (usually useEffect, useRef, and callbacks).

Prefer closures (I mean: small, local functions), strictly-typed TS interfaces, and async/await for everything. Avoid classes, fancy patterns, ORMs, function overloading, etc. Keep it simple.

Check out RunTypes for TypeScript. It will make moving data into & out of your codes breeze. Just JSON.stringy on one end and JSON.parse then MyRunType.check on the other end.

I'd agree with all these, but if I understood correctly OP wants to annotate static text rather than edit.

OP this is an interesting and rather niche area, you will want to be making use of the selection API[0] and figuring out a good way to make it reactive to integrate with react and your data model.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Selection

Ah, good point, TipTap may be overkill if OP doesn’t want to edit it at all.

You recommend Cypress as an "obvious" choice, so I am curious whether you evaluated Playwright. If you did, why you find Cypress to be the clearly superior choice? Genuine question.

Optimizing for community size and simplicity for an outsider.

Cypress is anything but simple. It takes a lot of time to learn all the footguns and not write flaky tests.

Thanks for the answer! I'm probably personally leaning towards using Playwright for future projects, reading that. I believe Playwright may be passing Cypress in community size, and simplicity is subjective. They both look quite similar, from this outsider's perspective.

Being someone that has recently evaluated the space and chosen Cypress I am curious why you think the community for Playwright may be passing Cypress? That name didn't even come up in my search while I found tons of blogs, discussions, walkthroughs, and discussion around Cypress. So many in fact I walked even confident I had chosen the 'easiest' tool where I classify easy as how hard it will be to find help when I am unclear on how to move forward.

Sure, I can clarify.

1. I know GitHub stars aren't everything, but Playwright has 41.9k at the moment, and Cypress has 40.5k.

2. Playwright is backed by Microsoft, and given how happy I've been with how they manage Typescript, that makes it a pretty safe bet to me.

3. Cypress is much older, so I discount a lot of the blog posts in my evaluations. In fact, I count such things against it sometimes, because oftentimes when I'm hunting for a solution to a problem, all I can find are outdated answers. I run into this a lot with AngularJS and Angular.

4. Playwright is included in most of the recent comparison articles I've run across. I don't really keep track of these, but searching again I quickly ran across 2 examples:

  * https://blog.checklyhq.com/cypress-vs-selenium-vs-playwright-vs-puppeteer-speed-comparison/
  * https://www.testim.io/blog/puppeteer-selenium-playwright-cypress-how-to-choose/

For a text editor, Lexical looks promising

https://github.com/facebook/lexical

To simplify and get started more quickly (JS tooling has become QUITE bloated and complex).

- Install Yarn (package manager) - Run: yarn create react-app THE_NAME_OF_YOUR_APP --template typescript - start hacking

For the mobile apps the missing piece of the puzzle is Capacitor.

Also, look for React Testing Library to complement Jest.

Reply on news.ycombinator.com