6 ms·
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 s
by chaos_emergent 4y ago
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!
- lucas_codes 4y agoI'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 https://developer.mozilla.org/en-US/docs/Web/API/Selection
- chaos_emergent 4y agoAh, good point, TipTap may be overkill if OP doesn’t want to edit it at all.
- Aldo_MX 4y agoFor the mobile apps the missing piece of the puzzle is Capacitor. Also, look for React Testing Library to complement Jest.
- ARussell 4y agoYou 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.
- chaos_emergent 4y agoOptimizing for community size and simplicity for an outsider.
- sjadoinqwoeihad 4y agoCypress is anything but simple. It takes a lot of time to learn all the footguns and not write flaky tests.
- ARussell 4y agoThanks 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.
- the_lonely_road 4y agoBeing 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.
- ARussell 4y agoSure, 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/
- DecoPerson 4y agoConcur 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.
- Bilal_io 4y agoFor a text editor, Lexical looks promising https://github.com/facebook/lexical https://github.com/facebook/lexical
- ravenstine 4y agoI 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.
- iainmerrick 4y agodon'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.
- joshcsimmons 4y agoTo 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