Ask HN: Help me pick a front-end framework
180 comments
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!
- 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.
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.
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.
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?
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.
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.
The benefits to using Typescript are immense.
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.
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.
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).
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.
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.
[deleted]
There is not reason whatsoever to use JS over TS for UI. None of the things you said are true.
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.
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
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.
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:
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/Cypress is anything but simple. It takes a lot of time to learn all the footguns and not write flaky tests.
For a text editor, Lexical looks promising
https://github.com/facebook/lexical
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
- 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.
Also, look for React Testing Library to complement Jest.
As a non-web developer who needed to learn a framework that "just works" for a hobby project, I suggest Svelte.
It was very easy to set up (I had previously had yelling and cursing matches with Angular).
Typescript integration is one little script away (and that script is included with the skeleton project every tutorial tells you to use).
Making a UI that "just works" is stupid simple. It's intuitive- easy to throw stuff together, but also easy to make things that scale and compose nicely. Svelte has been the most bullshit-free experience I've ever had in any of my web frontend escapades.
Frontend deployment? scp the build folder onto an EC2 instance running nginx. Done.
For styles? KISS. Use mvp.css. to use it, slap a single line of HTML into the top of index.svelte. Boom, everything is pretty enough that the average user will notice nothing out of the ordinary.
The stack I've settled on for my web projects is this:
- Svelte for the UI/UX.
- mvp.css for all of my styling needs.
- For the database/backend API/etc, Rails with postgres.
- Infrastructure? An ec2 instance. Nginx. Certbot, assuming that counts as infrastructure. Maybe some docker containers if I'm feeling fancy.
With this stack, a single person with very little web experience can have a fully-functioning MVP for a fairly sophisticated service deployed in a couple of weeks. It's unsophisticated, and it probably doesn't scale to a million billion users, but setup is easy, deployment is easy, maintenance is easy, and all of the necessary structure is there to let you scale up to a more sophisticated architecture later.
It was very easy to set up (I had previously had yelling and cursing matches with Angular).
Typescript integration is one little script away (and that script is included with the skeleton project every tutorial tells you to use).
Making a UI that "just works" is stupid simple. It's intuitive- easy to throw stuff together, but also easy to make things that scale and compose nicely. Svelte has been the most bullshit-free experience I've ever had in any of my web frontend escapades.
Frontend deployment? scp the build folder onto an EC2 instance running nginx. Done.
For styles? KISS. Use mvp.css. to use it, slap a single line of HTML into the top of index.svelte. Boom, everything is pretty enough that the average user will notice nothing out of the ordinary.
The stack I've settled on for my web projects is this:
- Svelte for the UI/UX.
- mvp.css for all of my styling needs.
- For the database/backend API/etc, Rails with postgres.
- Infrastructure? An ec2 instance. Nginx. Certbot, assuming that counts as infrastructure. Maybe some docker containers if I'm feeling fancy.
With this stack, a single person with very little web experience can have a fully-functioning MVP for a fairly sophisticated service deployed in a couple of weeks. It's unsophisticated, and it probably doesn't scale to a million billion users, but setup is easy, deployment is easy, maintenance is easy, and all of the necessary structure is there to let you scale up to a more sophisticated architecture later.
I'd add to try using sveltekit.
Typescript is already supported when you set it up using the documented "npm create svelte@next".
It has cool routing, backend etc but even if you don't care about any of it, you get free hot reloads. And with the new version, you can create it as if it was your average svelte app, just avoiding + in file names and using +page.svelte as your main entry point.
For styles, if you care about styling a bit more than default styles (mvp.css or bulma/bootstrap/similar), I'd recommend using tailwind's better clone windicss, which has great svelte integration (including editor extensions for autocomplete and highlight), and writing styles is quicker than using normal css.
You can also use scss/sass/similar in style blocks, you only need to install node-sass and set "scss"/"sass" as the lang of the style block.
Typescript is already supported when you set it up using the documented "npm create svelte@next".
It has cool routing, backend etc but even if you don't care about any of it, you get free hot reloads. And with the new version, you can create it as if it was your average svelte app, just avoiding + in file names and using +page.svelte as your main entry point.
For styles, if you care about styling a bit more than default styles (mvp.css or bulma/bootstrap/similar), I'd recommend using tailwind's better clone windicss, which has great svelte integration (including editor extensions for autocomplete and highlight), and writing styles is quicker than using normal css.
You can also use scss/sass/similar in style blocks, you only need to install node-sass and set "scss"/"sass" as the lang of the style block.
I love Svelte and SvelteKit but if you're just interested in building your app, please pick something else for now. It's still constantly changing and while it's good it's being developed rapidly, it's definitely not something you want to spend your limited time on migrating while you could just be productive with say React.
Okay sure, they have had big breaking changes in-between major versions as well, but before SvelteKit hits v1.0 you're better off using something more stable. Later you can certainly choose to migrate as the core logic probably is not that complex. If you're using rich-text editing capabilities however, React is more supported.
Okay sure, they have had big breaking changes in-between major versions as well, but before SvelteKit hits v1.0 you're better off using something more stable. Later you can certainly choose to migrate as the core logic probably is not that complex. If you're using rich-text editing capabilities however, React is more supported.
This is definitely worth noting. SveleteKit is probably close to 1.0, but the current versioning strategy is incrementing one number, and those changes are always expected to be breaking (even if they aren’t frequently breaking).
That said, if you start working on a given pre-release and only upgrade to 1.0, the migration shouldn’t be too painful.
That said, if you start working on a given pre-release and only upgrade to 1.0, the migration shouldn’t be too painful.
do note that sveltekit just entered a release candidate phase 2 days ago https://twitter.com/geoffrich_/status/1568264897905164289?s=...
meaning close to 1.0 and no further breaking changes expected
meaning close to 1.0 and no further breaking changes expected
Hey, great news! Appreciate your correction.
SvelteKit 1.0.0 has a release candidate since Friday. There have been many breaking changes leading up to that, but we’re past those now so this is an excellent time to start using it.
SvelteKit has indeed undergone a bunch of changes (and like others mentioned is now in the RC phase), but I just wanted to mention that Svelte itself has been very stable since v3 came out a few years ago.
Lets keep Svelte and SvelteKit straight! Kit is still changing, but Svelte is extremely stable and usable in prod.
Html + CSS + Javascript in 2022 is mostly what you need.
Unless your job is going to require a framework, it’s really not necessary.
Maybe I’m the old curmudgeon who is more concerned about putting out something that works and get customers/revenue quickly, than messing around with the latest Javascript toolchain to ensure it builds in Docker.
You csn get a ton done with Javascript and Tailwind or DaisyUI. In fact almost 90% of what you need.
And with the advent of new backend frameworks like Liveview that patch the dom, I believe things like Angular, React, Vue are on the dying list.
Unless your job is going to require a framework, it’s really not necessary.
Maybe I’m the old curmudgeon who is more concerned about putting out something that works and get customers/revenue quickly, than messing around with the latest Javascript toolchain to ensure it builds in Docker.
You csn get a ton done with Javascript and Tailwind or DaisyUI. In fact almost 90% of what you need.
And with the advent of new backend frameworks like Liveview that patch the dom, I believe things like Angular, React, Vue are on the dying list.
> Unless your job is going to require a framework, it’s really not necessary.
Respectfully disagree. Mirroring your state in the DOM on your own is incredibly easy to get wrong. Doesn't matter if it's react, svelte or vue, any such framework will greatly simplify the UI parts. Aside from that though, I agree you can (and probably should) avoid most deps.
Respectfully disagree. Mirroring your state in the DOM on your own is incredibly easy to get wrong. Doesn't matter if it's react, svelte or vue, any such framework will greatly simplify the UI parts. Aside from that though, I agree you can (and probably should) avoid most deps.
I found using web components with Lit got me most of the way there to allowing individual components to self contain their state and redraw as required when state changed.
For prototyping and simple things, instead of mirroring my state in the DOM, I use the DOM to store state. Yes, it isn't quite as performant, but for this sort of work that doesn't usually matter.
> For prototyping and simple things, instead of mirroring my state in the DOM, I use the DOM to store state.
I find it funny that people think mirroring the DOM will magically make your web app performant. I've visited plenty of React sites that are sluggish, bloated, load slowly and a pain to use. I've also visited plenty of plain ol' HTML/CSS/JS sites that are snappy, load quickly, and fast enough. No framework or clever algorithm will save you from crappy code ;)
I find it funny that people think mirroring the DOM will magically make your web app performant. I've visited plenty of React sites that are sluggish, bloated, load slowly and a pain to use. I've also visited plenty of plain ol' HTML/CSS/JS sites that are snappy, load quickly, and fast enough. No framework or clever algorithm will save you from crappy code ;)
I don't think it will magically make your code performant, but I've written things where using the DOM for state was pretty painfully inefficient. For example, multiple queries over a large amount of data where data is only represented as DOM notes. When working on small things and prototypes, though, this has been the exception, and I'm happy to mostly just use the DOM.
I didn’t quite follow the OP’s description of the app, but it sounds like the sort of app where you’ll end up having to do a lot of raw DOM manipulation / selection logic.
I actually think vanilla JS / TS might be the best fit, here. You’ll probably be writing a lot of plain JS anyway based on my understanding of the description, so I’m not sure a framework buys you much.
I highly recommend Tailwind for CSS and Playwright for testing the real UI.
I actually think vanilla JS / TS might be the best fit, here. You’ll probably be writing a lot of plain JS anyway based on my understanding of the description, so I’m not sure a framework buys you much.
I highly recommend Tailwind for CSS and Playwright for testing the real UI.
As in every post about front-end frameworks, I must mention HTMX and Unpoly:
https://htmx.org/
https://unpoly.com/
To learn more about the concept, please take a look at Essays here: https://htmx.org/essays/
https://htmx.org/
https://unpoly.com/
To learn more about the concept, please take a look at Essays here: https://htmx.org/essays/
Is Unpoly alternative to HTMX? Or could the two be complementary?
they are alternatives, not complementary. Unpoly seems to include more features, layers are particularly impressive.
Vue is the sort of GUI framework I would've written if I had the talent to do so. Thanks to its reactive nature, powerful things can be extremely easy. Very nice if one knows what they're doing. Power can be misused by the less experienced but what can't?
TS support is optional. <script lang="ts"> and boom - a TS component right there.
I've only spent a day with Svelte but I did like what I saw. Very nice indeed. Anyone with experience building complex apps with it should chime in.
TS support is optional. <script lang="ts"> and boom - a TS component right there.
I've only spent a day with Svelte but I did like what I saw. Very nice indeed. Anyone with experience building complex apps with it should chime in.
> "building a text-annotation based app"
I'm going to assume that you are talking about a desktop-based webapp that is also responsive, and not a native app.
I have 10+ years of experience doing front-end, with probably over a dozen React packages self-published in npm, and also tried making a rich text editor ~6 years back[1]. I actually recommend starting with no framework at all (please read on).
Creating a rich text editor might be the hardest thing you can do in "normal" front-end (excluding some more advanced "frontend" fields like 3D or games). You can either manipulate raw cursors, which will be very tricky because I'm not even sure you have access to all the right APIs (specially on mobile), or you can attempt to use Contenteditable, which is a hell of its own[2].
"All problems start with caret placing and multi browser support" [3]
That said, I believe 90% of the complexity of your app will be here, around the actual interaction with the <textarea> or <div contenteditable> that you will be using. For that, no framework will really help you, at all. So my recommendation is to first get that working, which will take weeks/months and probably thousands of lines of code, and then worry about placing the little hovering boxes in their place (the "UI"), which is like 30-40 lines of JS/CSS[4].
Once you have this core interaction working, you can also wrap it in your preferred frontend framework for other people to easily use it.
[1] https://github.com/franciscop/modern-editor
[2] https://answerly.io/blog/my-pain-developing-a-wysiwyg-editor...
[3] https://news.ycombinator.com/item?id=27938702
[4] https://stackoverflow.com/q/4495626/938236
I'm going to assume that you are talking about a desktop-based webapp that is also responsive, and not a native app.
I have 10+ years of experience doing front-end, with probably over a dozen React packages self-published in npm, and also tried making a rich text editor ~6 years back[1]. I actually recommend starting with no framework at all (please read on).
Creating a rich text editor might be the hardest thing you can do in "normal" front-end (excluding some more advanced "frontend" fields like 3D or games). You can either manipulate raw cursors, which will be very tricky because I'm not even sure you have access to all the right APIs (specially on mobile), or you can attempt to use Contenteditable, which is a hell of its own[2].
"All problems start with caret placing and multi browser support" [3]
That said, I believe 90% of the complexity of your app will be here, around the actual interaction with the <textarea> or <div contenteditable> that you will be using. For that, no framework will really help you, at all. So my recommendation is to first get that working, which will take weeks/months and probably thousands of lines of code, and then worry about placing the little hovering boxes in their place (the "UI"), which is like 30-40 lines of JS/CSS[4].
Once you have this core interaction working, you can also wrap it in your preferred frontend framework for other people to easily use it.
[1] https://github.com/franciscop/modern-editor
[2] https://answerly.io/blog/my-pain-developing-a-wysiwyg-editor...
[3] https://news.ycombinator.com/item?id=27938702
[4] https://stackoverflow.com/q/4495626/938236
Might make sense to just start with an existing rich text editor (with a friendly license) that you fork. You'll have your own needs but a large part of any editor is common to every other editor. Or maybe you could just spend a few days reviewing the source of existing editors as inspiration. Seems nuts to just go for it yourself especially since OP is saying they aren't super experienced in TS FE.
Based on your requirements and resources I would recommend using plain simple JavaScript over any framework. The time you would spend learning any framework or build system would be better spent iterating on your core experience and experimenting with things that come out-of-the-box on modern web browsers. Frameworks inevitably drag you into their ecosystem where everyone marches at a certain pace. While there are benefits to this, I think it would be a distraction for you. Furthermore, there are many arcane JavaScript libraries that you may find useful down the road, and it is much easier to drag-and-drop them into your project with HTML "<script>" compared to fighting with module bundler du jour.
I agree with the other comments suggesting React. I actually typically recommend just plain HTML and CSS for most projects. But it sounds like you’re building something with a lot of interactivity, so something like React (or Vue or Svelte) is going to make your life a lot easier.
I also agree with other comments that you should postpone worrying about iOS/Android apps for now. Targeting those platforms adds a lot of complexity and will slow you down. So you should avoid them unless your app really only makes sense as a native mobile app.
If down the road you do decide that you want native mobile apps, I recommend using React Native with Expo. Transitioning from React to React Native is relatively easy (from a concepts perspective). But React Native doesn’t use HTML or real CSS (although it’s heavily inspired by it), so you will need to rewrite a lot of your code and change all of your dependencies over to React Native-compatible versions. With React Native, you can have a single code base that targets web, iOS and Android so you don’t need to maintain multiple versions of your code.
If you don’t like React Native for some reason (e.g., it’s made by Meta), you can also look into Flutter which is made by Google.
I also agree with other comments that you should postpone worrying about iOS/Android apps for now. Targeting those platforms adds a lot of complexity and will slow you down. So you should avoid them unless your app really only makes sense as a native mobile app.
If down the road you do decide that you want native mobile apps, I recommend using React Native with Expo. Transitioning from React to React Native is relatively easy (from a concepts perspective). But React Native doesn’t use HTML or real CSS (although it’s heavily inspired by it), so you will need to rewrite a lot of your code and change all of your dependencies over to React Native-compatible versions. With React Native, you can have a single code base that targets web, iOS and Android so you don’t need to maintain multiple versions of your code.
If you don’t like React Native for some reason (e.g., it’s made by Meta), you can also look into Flutter which is made by Google.
My two cents: you have too many requirements that will cause paralysis.
For example, don't worry about the Android or iOS idea yet. You are going to have trouble just getting the basic app done. Do that first and then you will need to throw it away once you understand what you need to build.
If it were me, I would use svelte. Much better than react and satisfies your need for typescript. Use storybook for UI testing, just shift your thinking about that idea...
For example, don't worry about the Android or iOS idea yet. You are going to have trouble just getting the basic app done. Do that first and then you will need to throw it away once you understand what you need to build.
If it were me, I would use svelte. Much better than react and satisfies your need for typescript. Use storybook for UI testing, just shift your thinking about that idea...
For styling, I've had good success with Daisy UI which is based off tailwind. The author loves svelte even though it isn't svelte specific.
I would suggest you to take a look at https://svelte.dev/. It's fast, has TypeScript support and is very easy to learn. I've been using React for many years, but after trying out Svelte, I am coming to the conclusion that Svelte is much more fun and more powerful. For example, it supports a global store out of the box. On the other side, it's not as mature as other frameworks, probably. Also, in my experience with React Hooks you tend to get into a very complex dependency and rendering logic and the code can be very hard to understand after many hooks were added (but that's another topic).
I have to say Svelte is my first thought, even though it explicitly misses some of the criteria.
There's a lot of criteria in the original question, which will inexorably lead you to React.
But for learning fast from scratch and doing lots of iteration and rewrites on a very complex UI, Svelte is going to provide a leg up.
The biggest issue is finding a UI library you are happy with, and dealing with inevitable Sveltekit changes. I used tailwind and it integrates ok with Svelte. And I've just resigned myself to dealing with Sveltekit updates.
There's a lot of criteria in the original question, which will inexorably lead you to React.
But for learning fast from scratch and doing lots of iteration and rewrites on a very complex UI, Svelte is going to provide a leg up.
The biggest issue is finding a UI library you are happy with, and dealing with inevitable Sveltekit changes. I used tailwind and it integrates ok with Svelte. And I've just resigned myself to dealing with Sveltekit updates.
No more dealing with SvelteKit changes, we've hit RC! :)
I would cautiously recommend considering Elm.
Pros: - strict typing across the ecosystem with best in class DX around typechecking
- ease of refactoring and making large scale changes in your app. I can’t overemphasise this one. At work we have switched out out UI system several times across several apps, which would have been a Herculean task in most other front end tools. Here it was an entirely painless, even easy (if somewhat laborious) task.
- stability. Elm is very stable in its features, there is almost no churn.
- good testing library (sort of) built in with property based testing
- the elm-ui library abstracts CSS for you. This takes away some of the trickiest parts of “front-end”
Cons: - if you need to deal a lot with imperative DOM apis, this can have a bit more friction than in other solutions. Usually this involves writing webcomponents in plain js or ts and calling those from your Elm code with event driven communication between them. Our relatively complex web apps at work each use about half a dozen of these, so is usually manageable, but in some cases this can be a lot worse. Probably worth looking into.
- somewhat unusual OSS project leadership. If you don’t expect to have any influence on the direction or pace of Elm as such, you’ll be happy.
Pros: - strict typing across the ecosystem with best in class DX around typechecking
- ease of refactoring and making large scale changes in your app. I can’t overemphasise this one. At work we have switched out out UI system several times across several apps, which would have been a Herculean task in most other front end tools. Here it was an entirely painless, even easy (if somewhat laborious) task.
- stability. Elm is very stable in its features, there is almost no churn.
- good testing library (sort of) built in with property based testing
- the elm-ui library abstracts CSS for you. This takes away some of the trickiest parts of “front-end”
Cons: - if you need to deal a lot with imperative DOM apis, this can have a bit more friction than in other solutions. Usually this involves writing webcomponents in plain js or ts and calling those from your Elm code with event driven communication between them. Our relatively complex web apps at work each use about half a dozen of these, so is usually manageable, but in some cases this can be a lot worse. Probably worth looking into.
- somewhat unusual OSS project leadership. If you don’t expect to have any influence on the direction or pace of Elm as such, you’ll be happy.
OP, I didn’t grok the description of what you’re trying to build enough to have a useful suggestion for you, but as a word of caution you’re probably going to get a lot of responses that don’t take into account you’re specific situation but instead are based on the commenter’s current favorite front end tool. As someone who is pretty new to front end development, you would do well to stick with standard tooling like React. For all its flaws it has a robust community around it that will make it easier for you to get help when you get stuck, and libraries that will do some of the work for you.
How fast can I do the least work?
React.
Never "how can I do the most maintainable code", "how can I write good code".
React.
Never "how can I do the most maintainable code", "how can I write good code".
> Does anyone still write plain JS
Yes, I'm finishing a game in plain vanilla js :)
For rapid prototyping I'd suggest React. It has the richest ecosystem, already existing knowledge base (SO, blog posts, courses...) and whole bunch of components available.
If you don't have a good sense for UI-s, then try an opinionated one, like Tailwind or one of its alternatives, Google will help find some. It plays really well with React. Pick on that looks the most intuitive to you and has a great component documentation.
Typescript is indeed a good idea if maintainability is a design goal.
Yes, I'm finishing a game in plain vanilla js :)
For rapid prototyping I'd suggest React. It has the richest ecosystem, already existing knowledge base (SO, blog posts, courses...) and whole bunch of components available.
If you don't have a good sense for UI-s, then try an opinionated one, like Tailwind or one of its alternatives, Google will help find some. It plays really well with React. Pick on that looks the most intuitive to you and has a great component documentation.
Typescript is indeed a good idea if maintainability is a design goal.
Vue2, Vue3, or React.
React has a larger community but requires you to make a lot of decisions yourself. Also well integrated with Typescript.
Vue2 is the only of these three that can be added to a webpage with a script tag. In that sense, it is a lot more simple than the other options. Still a pretty big community. Typescript integration is meh.
Vue3 is Vue2 with better typescript integration but with tooling a bit more similar to React. Not big yet but will be.
All three will be fine in ten years I'm pretty sure.
I'd actually start off looking to see if there is a Frontend Compnent Library (like Vuetify, etc) that works with one of these three that does part of what you want first as that is more likely to be the tipping point for what you should use.
React has a larger community but requires you to make a lot of decisions yourself. Also well integrated with Typescript.
Vue2 is the only of these three that can be added to a webpage with a script tag. In that sense, it is a lot more simple than the other options. Still a pretty big community. Typescript integration is meh.
Vue3 is Vue2 with better typescript integration but with tooling a bit more similar to React. Not big yet but will be.
All three will be fine in ten years I'm pretty sure.
I'd actually start off looking to see if there is a Frontend Compnent Library (like Vuetify, etc) that works with one of these three that does part of what you want first as that is more likely to be the tipping point for what you should use.
> Vue2 is the only of these three that can be added to a webpage with a script tag. In that sense, it is a lot more simple than the other options.
Is that really that big of a differentiator? I definitely see the appeal especially in getting stuff out the door quickly, but I wouldn’t consider it in a comparison.
Is that really that big of a differentiator? I definitely see the appeal especially in getting stuff out the door quickly, but I wouldn’t consider it in a comparison.
It was to me. And a good portion of Vue2 frameworks were built with that in mind, which is kinda nice.
I know the other poster said you could so react with a script tag... just looked and apparently it is possible... but I don't know many people who use it that way. Something new I learned though.
I know the other poster said you could so react with a script tag... just looked and apparently it is possible... but I don't know many people who use it that way. Something new I learned though.
It's also not true, React can be used with a single script tag
Is there documentation / examples around this concept? I remember getting something basic working in 2015 but nothing where you just drop in a script tag anywhere
I would not start any new projects on Vue 2, because you won’t get bugfixes in the future. Vue 3 or React.
Svelte / Sveltkit is easy to learn, efficient and separates HTML, JS, CSS nicely (no need to mess around with JSX). It supports Typescript and you get animations, global state etc. out of the box. Downside: it's top notch and thus hasn't the biggest ecosystem yet.
You can also try Flutter for developing mobile, desktop and web apps. It's got Google's backing and is also supported by Canonical for Ubuntu desktop apps.
You can also try Flutter for developing mobile, desktop and web apps. It's got Google's backing and is also supported by Canonical for Ubuntu desktop apps.
I’ll recommend two paths…
Working alone, there is no easier setup than Laravel and (probably for you) Vue + Inertia. Vue is a major player with lots of available packages and it’s pretty simple to get setup with Laravel for a database and backend. If you need help getting started, Laracasts is unmatched in terms of tutorial quality.
The other path is to use React. If you think you want a job in front end development, spending time in react will broaden your eligible job set by a significant margin. I personally don’t like react, but it’s going to dominate front-end for the next five years at least.
Best of luck!
Working alone, there is no easier setup than Laravel and (probably for you) Vue + Inertia. Vue is a major player with lots of available packages and it’s pretty simple to get setup with Laravel for a database and backend. If you need help getting started, Laracasts is unmatched in terms of tutorial quality.
The other path is to use React. If you think you want a job in front end development, spending time in react will broaden your eligible job set by a significant margin. I personally don’t like react, but it’s going to dominate front-end for the next five years at least.
Best of luck!
There's also livewire plus filament admin on the backend. Makes coding a breeze.
If you expect to start from scratch several times, I encourage you to separate your logic from your views. Whatever framework you decide to try, make it as thing a layer as possible, and put as much code and functionality as possible in framework-agnostic, plain JS files.
In this way, adding, removing, or changing your frontend framework becomes much simpler. They had a more straightforward role in your system ("when user interacts with X call module Y.foo") instead of housing most of your code, and potentially losing all that code when you start from scratch or decide to try a different framework.
Secondly, get a better idea of what your needs are. Do you just need a few UI interactions? Is it going to be heavy on state? Do you need to run a lot of AJAX requests and update the UI accordingly? Before you can know which JS framework you need, you need to know what role the JS plays in your system. If you don't do that, every framework is a potential valid answer, since the question is too vaguely defined.
In this way, adding, removing, or changing your frontend framework becomes much simpler. They had a more straightforward role in your system ("when user interacts with X call module Y.foo") instead of housing most of your code, and potentially losing all that code when you start from scratch or decide to try a different framework.
Secondly, get a better idea of what your needs are. Do you just need a few UI interactions? Is it going to be heavy on state? Do you need to run a lot of AJAX requests and update the UI accordingly? Before you can know which JS framework you need, you need to know what role the JS plays in your system. If you don't do that, every framework is a potential valid answer, since the question is too vaguely defined.
Agreed. When writing my code editor I started off with a lot of UI-related state and logic in the UI (Svelte) components, things like keeping track of what tabs are open and editor state within the tabs.
Quickly realised there was gonna be a lot of grappling with Svelte as the complexity grew: figuring out what component structure to use for passing data around efficiently and ergonomically, passing events between components, using Svelte stores for global state and figuring out how to update and subscribe to them from non-Svelte code, etc.
Now the Svelte code is a thin wrapper and the app can run headless. I feel like it would genuinely be fairly easy to plug a totally different UI onto it.
Each Svelte component basically stores copies of the state it's interested in, subscribes to events from the objects it's interested in, and calls methods on those objects in response to events. This comes with a bit of extra boilerplate vs. more tightly integrating the UI logic with Svelte but the almost complete lack of cognitive overhead in this part of the code is well worth it.
Quickly realised there was gonna be a lot of grappling with Svelte as the complexity grew: figuring out what component structure to use for passing data around efficiently and ergonomically, passing events between components, using Svelte stores for global state and figuring out how to update and subscribe to them from non-Svelte code, etc.
Now the Svelte code is a thin wrapper and the app can run headless. I feel like it would genuinely be fairly easy to plug a totally different UI onto it.
Each Svelte component basically stores copies of the state it's interested in, subscribes to events from the objects it's interested in, and calls methods on those objects in response to events. This comes with a bit of extra boilerplate vs. more tightly integrating the UI logic with Svelte but the almost complete lack of cognitive overhead in this part of the code is well worth it.
"prototyping quickly" and "quick rampup" are for me a bit contradictory to "weak typing is a deal breaker". If I do not have to define types for everything, I am WAY faster with my prototypes.
Also given that it is frontend land, I am not sure any of the tools now available will be available (and compatible) in 10 years. And because it is a side project I would not spend one second worrying about 10 years from now.
HN will not tell you what you will like. Every now and then a question like this is asked and people just tell OP the tools they currently use.
I guess it would be best to create a mini app (reading a list of things from a backend and render it and maybe delete something from the list) in two or three frontend frameworks and then choose the one that felt the nicest for you.
As for design I guess Tailwind CSS is something for you. It is easy to make web sites that look nice. (All tailwind CSS sites look kind of the same, but this is OK)
Good luck with you project!
Also given that it is frontend land, I am not sure any of the tools now available will be available (and compatible) in 10 years. And because it is a side project I would not spend one second worrying about 10 years from now.
HN will not tell you what you will like. Every now and then a question like this is asked and people just tell OP the tools they currently use.
I guess it would be best to create a mini app (reading a list of things from a backend and render it and maybe delete something from the list) in two or three frontend frameworks and then choose the one that felt the nicest for you.
As for design I guess Tailwind CSS is something for you. It is easy to make web sites that look nice. (All tailwind CSS sites look kind of the same, but this is OK)
Good luck with you project!
> guess it would be best to create a mini app (reading a list of things from a backend and render it and maybe delete something from the list) in two or three frontend frameworks and then choose the one that felt the nicest for you.
This is really good advice. I did that when evaluating react, vue and angular once upon a time. It was pretty clear to me after that what framework i would like to work with, despite what people said about each one at the time.
This is really good advice. I did that when evaluating react, vue and angular once upon a time. It was pretty clear to me after that what framework i would like to work with, despite what people said about each one at the time.
The threshold for when static typing becomes faster than dynamic typing is waaaaay smaller than "a full app". At least if you actually take advantage of them, e.g. by using an IDE.
> Because of limited time, and low confidence in UX design decisions, I would often follow the path of least resistance and the end product would be heavily influenced by the tools I used to build it.
Angular with the Angular Material components library would be very "batteries-included". You don't have to decide how you store state, what testing framework to use, etc. Angular provides sane defaults for most things. And it also ticks your TypeScript requirement.
> Relatedly, I expect to get the UX design horribly horribly wrong and start from scratch at least once. I also suck at making things look pretty and also don't find this problem very rewardinging to think or read about.
With angular material, you'll get pre-built and pre-styled navigation menus, form inputs, etc. Wiring them up to your TypeScript code will be a breeze but it'll be tough to customize them if you're going for somewhat unique / unusual behavior or styling. And occasionally you'll need something commonplace like a time picker and the library won't have that.
> I don't think I'll want a native desktop app but an iOS/Android version could make sense.
The simplest route to putting your app in the app store / play store is called a Progressive Web App (PWA). For which you basically need a config json and some icons. The gotcha is that PWAs have virtually zero access to native features.
> I don't really have the discipline for manual testing. Luckily I also find it satisfying to over-invest in test automation. I don't really know how this is done in frontend land but good tooling would be a big plus.
Angular uses Jasmine by default for unit tests. You can test both the business logic and UI interactions this way, but in my experience mocking out components is annoying and a fuckton of maintenance. I usually stick with testing the logic or clumps of un-mocked components. There's also support for end-to-end tests using Protractor, but I'm not super familiar with it.
> I'm happy to sacrifice one or more of the other requirements in favour of tools that are likely to be maintained 10 years from now.
Angular will probably be around 10 years from now, but I doubt keeping the version / other dependency versions up-to-date will be painless. Some things are just kinda deprecated / replaced for lame reasons (but you'll have notice of these changes waaay in advance).
Angular with the Angular Material components library would be very "batteries-included". You don't have to decide how you store state, what testing framework to use, etc. Angular provides sane defaults for most things. And it also ticks your TypeScript requirement.
> Relatedly, I expect to get the UX design horribly horribly wrong and start from scratch at least once. I also suck at making things look pretty and also don't find this problem very rewardinging to think or read about.
With angular material, you'll get pre-built and pre-styled navigation menus, form inputs, etc. Wiring them up to your TypeScript code will be a breeze but it'll be tough to customize them if you're going for somewhat unique / unusual behavior or styling. And occasionally you'll need something commonplace like a time picker and the library won't have that.
> I don't think I'll want a native desktop app but an iOS/Android version could make sense.
The simplest route to putting your app in the app store / play store is called a Progressive Web App (PWA). For which you basically need a config json and some icons. The gotcha is that PWAs have virtually zero access to native features.
> I don't really have the discipline for manual testing. Luckily I also find it satisfying to over-invest in test automation. I don't really know how this is done in frontend land but good tooling would be a big plus.
Angular uses Jasmine by default for unit tests. You can test both the business logic and UI interactions this way, but in my experience mocking out components is annoying and a fuckton of maintenance. I usually stick with testing the logic or clumps of un-mocked components. There's also support for end-to-end tests using Protractor, but I'm not super familiar with it.
> I'm happy to sacrifice one or more of the other requirements in favour of tools that are likely to be maintained 10 years from now.
Angular will probably be around 10 years from now, but I doubt keeping the version / other dependency versions up-to-date will be painless. Some things are just kinda deprecated / replaced for lame reasons (but you'll have notice of these changes waaay in advance).
Angular markets itself as a tricycle but comes with a manual in which the first chapter after the introduction instructs you to swap out your wheels for jet engines. The learning curve and hidden complexity is absolutely insane and I would only recommend choosing Angular in extreme cases where you actually need to break the sound barrier.
Source: I maintain a complex Angular SPA since AngularJS/2.
Source: I maintain a complex Angular SPA since AngularJS/2.
Yeah, this description doesn't sit with me very well, either. I fully support the argument that Angular is not a good choice because React is more popular and has a larger pool of developers, but not that it is more complex.
I too would like to hear about what complexities you are encountering and if they are incidental or necessary complexities.
I too would like to hear about what complexities you are encountering and if they are incidental or necessary complexities.
?
This reads like too much cool aid.
Angular is an entirely application stack, “choices made for you”. uses dependency injection out of the box, has a complex module system (eg. How you used to have import Material components one by one). It’s observables all the way down.
How can you argue that’s not complex? It’s super complex.
I mean, let’s just take an example, say, making a library… https://angular.io/guide/creating-libraries
Now let’s look at https://kit.svelte.dev/docs/packaging
Quite the difference.
I’m a modest fan of angular because it produces good stuff… but not because it’s simple or easy to learn.
You get good solid engineering outcomes with it.
This reads like too much cool aid.
Angular is an entirely application stack, “choices made for you”. uses dependency injection out of the box, has a complex module system (eg. How you used to have import Material components one by one). It’s observables all the way down.
How can you argue that’s not complex? It’s super complex.
I mean, let’s just take an example, say, making a library… https://angular.io/guide/creating-libraries
Now let’s look at https://kit.svelte.dev/docs/packaging
Quite the difference.
I’m a modest fan of angular because it produces good stuff… but not because it’s simple or easy to learn.
You get good solid engineering outcomes with it.
Can you elaborate on some of your challenges please?
I find it quite straight forward to use once you overcome the somewhat steep learning curve.
I find it quite straight forward to use once you overcome the somewhat steep learning curve.
Sure, the following challenges come to mind:
* Must maintain a deep understanding of RxJS, which is its own beast. Angular team sometimes uses it in "creative" ways that change between versions in creative ways.
* Must not go off reservation (or do) where the Angular code is committed but not covered by documentation (because reasons). Template variables (hack an ngIf into an ngVar) come to mind, as well as how not subclass an abstract component (e.g. abstract component can technically have its own template and interesting things happen when children also have their own templates).
* Must understand how Angular i18n works by inspecting various Angular code repositories (and sometimes having to build the Angular project yourself, inadvertently discovering the "wonders" of Bazel). For example, the list of Angular supported locales is generated from CLDR dumps. CLDR likes to release new dumps and so the list of Angular supported locales changes (sometimes). You can think of interview Angular questions from hell such as what is the default build locale and what happens if you change it to "en-US-POSIX"? Or, my current favorite, how to ask Angular put dir="rtl" into the generated index.html for locales that are RTL?
These are just off the top of my head. I didn't even go into various performance optimization techniques which may or may not be made redundant by the next version of Angular because of their own compiler optimizations. Also, having to make the decision of the E2E testing solution (or sticking with Protractor).
* Must maintain a deep understanding of RxJS, which is its own beast. Angular team sometimes uses it in "creative" ways that change between versions in creative ways.
* Must not go off reservation (or do) where the Angular code is committed but not covered by documentation (because reasons). Template variables (hack an ngIf into an ngVar) come to mind, as well as how not subclass an abstract component (e.g. abstract component can technically have its own template and interesting things happen when children also have their own templates).
* Must understand how Angular i18n works by inspecting various Angular code repositories (and sometimes having to build the Angular project yourself, inadvertently discovering the "wonders" of Bazel). For example, the list of Angular supported locales is generated from CLDR dumps. CLDR likes to release new dumps and so the list of Angular supported locales changes (sometimes). You can think of interview Angular questions from hell such as what is the default build locale and what happens if you change it to "en-US-POSIX"? Or, my current favorite, how to ask Angular put dir="rtl" into the generated index.html for locales that are RTL?
These are just off the top of my head. I didn't even go into various performance optimization techniques which may or may not be made redundant by the next version of Angular because of their own compiler optimizations. Also, having to make the decision of the E2E testing solution (or sticking with Protractor).
While I do agree with you, I must admit that some of these reasons could be subjective. That being said, Angular has its share of issues. However, I find the overall developer experience to be good and I usually find the code to be well organized in projects.
+1 to angular being "batteries included". If you need to ask what framework to use, pick angular as all of the hard choices have already been made.
You don't have to make any more choices after picking angular - you are all set and everything not only works together perfectly complete with extensive documentation for the whole thing, but you also get a professionally maintained UI framework designed to work with it.
Compare with react which is just the first of many subsequent and continual choices you will need to keep on making as sub-frameworks come and go and need to be replaced as you maintain your app e.g. major security issue in foo 1.1 but you can't upgrade as it has a dependency on boo 1.2 that has not been updated so you need to switch to quux 0.9a but that changes how forms are handled so you need to refactor your apps routing, and that breaks your test framework etc, then someone deletes the leftpad repo and none of your dependencies work anymore anyway etc (oh and by the way your NPM install is out of date too so upgrade that first). Then factor in fighting with NPM & node, dealing with separate documentation for different sub-frameworks, your effort and sanity from trying to integrate them etc. I am perplexed as to why anyone would pick react for anything apart from the most trivial of UIs - it is a nightmare.
Angular will be around for a long time - it is used extensively in enterprise environments and Google.are throwing SWEs at it even if the vocal cool kids are using react or Vue or whatever.
You don't have to make any more choices after picking angular - you are all set and everything not only works together perfectly complete with extensive documentation for the whole thing, but you also get a professionally maintained UI framework designed to work with it.
Compare with react which is just the first of many subsequent and continual choices you will need to keep on making as sub-frameworks come and go and need to be replaced as you maintain your app e.g. major security issue in foo 1.1 but you can't upgrade as it has a dependency on boo 1.2 that has not been updated so you need to switch to quux 0.9a but that changes how forms are handled so you need to refactor your apps routing, and that breaks your test framework etc, then someone deletes the leftpad repo and none of your dependencies work anymore anyway etc (oh and by the way your NPM install is out of date too so upgrade that first). Then factor in fighting with NPM & node, dealing with separate documentation for different sub-frameworks, your effort and sanity from trying to integrate them etc. I am perplexed as to why anyone would pick react for anything apart from the most trivial of UIs - it is a nightmare.
Angular will be around for a long time - it is used extensively in enterprise environments and Google.are throwing SWEs at it even if the vocal cool kids are using react or Vue or whatever.
I agree. I chose React only for the simple reason there are more React jobs than Angular out there.
> The gotcha is that PWAs have virtually zero access to native features.
Huh?
Lots been done in this space — what are you still missing?
Huh?
Lots been done in this space — what are you still missing?
Quasar lets you deploy spa, SSR, electron, android and iOS, reusing what's appropriate. It uses Vue.
But my real advice is go kick the tyres. Try hello world in half a dozen candidates.
Take a thin vertical slice through your app, and try implementing in your short list of frameworks.
It will be worth the investment
But my real advice is go kick the tyres. Try hello world in half a dozen candidates.
Take a thin vertical slice through your app, and try implementing in your short list of frameworks.
It will be worth the investment
I find Vue easier to learn than React and its documentation is great.
+1. I also recommend this template[1] based on Vitesse, a starter project created by one member of Vue core team. It includes the NaiveUI library with many advanced components ready.
[1] https://github.com/arijs/vitesse-modular-naiveui
[1] https://github.com/arijs/vitesse-modular-naiveui
Maybe have a look at Stencil (+ Ionic). https://stenciljs.com/
Pro:
- Simple to learn
- Doesn't change all the time
- First-class TypeScript support
- Good default UI via Ionic
- Compiles to Web Components (although to be honest, this doesn't really matter)
- Easy testing
- Ionic as a company invests in Ionic the framework + Stencil the compiler. Might be around in 10 years, altough things could change. But this is true for all frameworks.
- You basically get an iOS/Android app for free, if you just dump the output in Capacitor (also developed by Ionic the company).
Cons:
- Stencil is not very widespread as a frontend framework.
Pro:
- Simple to learn
- Doesn't change all the time
- First-class TypeScript support
- Good default UI via Ionic
- Compiles to Web Components (although to be honest, this doesn't really matter)
- Easy testing
- Ionic as a company invests in Ionic the framework + Stencil the compiler. Might be around in 10 years, altough things could change. But this is true for all frameworks.
- You basically get an iOS/Android app for free, if you just dump the output in Capacitor (also developed by Ionic the company).
Cons:
- Stencil is not very widespread as a frontend framework.
Try Flutter (Dart). Picked it up for a gig this summer. Strong typing, great performance, diagnostic tools are capable, instant hot reload, and it can be compiled for any platform.
The main factor that might make or break it for your usecase is whether it supports the kind of advanced text layout you might need.
The main factor that might make or break it for your usecase is whether it supports the kind of advanced text layout you might need.
Second the recommendation for Flutter, very robust dev environment.
> text annotation app
You could find plain JS to be sufficient for this. I'm guess you're highlighting the text a popup will come up and you submit to a server?
If you really want to use a framework, Svelte could be a good choice. If you want to stay with safer choices then React with Mobx, or something else that uses subscriptions to bypass React's default rendering. The other thing you could do is test out each one and figure out what you like the best, because some of it is subjective.
You could find plain JS to be sufficient for this. I'm guess you're highlighting the text a popup will come up and you submit to a server?
If you really want to use a framework, Svelte could be a good choice. If you want to stay with safer choices then React with Mobx, or something else that uses subscriptions to bypass React's default rendering. The other thing you could do is test out each one and figure out what you like the best, because some of it is subjective.
Do not over complicate your stack.
It will happen on its own.
Building product is part product and part distribution (customer acquisition).
The more established or boring tech you use, the more time you have to understand the problem and needs and iterate more often and quicker. Often just using what you know isn’t as bad idea. It will shed a light on where you wanna be with your final tech stack anyways. Customers generally don’t care what you have coded their solution in.
Your goal is more to build a flexible feature testing system / experimentation engine that can bill for money (presume the billing part).
The context of what problem you’re solving is secondary because it will change and evolve.
Today I would consider starting with:
- TryCelery - no presales, no demand
- Tailwind UI wireframe or PoC in HTML. Meant to be disposable. Shuffle.dev is a handy tool.
- Flutter to recreate and build the prototype, aloha and mvp to have one code hit to hit all platforms including web. Forget is generally newer and next green collated to it’s contemporaries.
Don’t work with tailwind or flutter? Hire a product designer and dev to not build it for you but teach you both via screen shares from UPWork, etc. If they can teach you how they can probably build it vs saying they can.
It will happen on its own.
Building product is part product and part distribution (customer acquisition).
The more established or boring tech you use, the more time you have to understand the problem and needs and iterate more often and quicker. Often just using what you know isn’t as bad idea. It will shed a light on where you wanna be with your final tech stack anyways. Customers generally don’t care what you have coded their solution in.
Your goal is more to build a flexible feature testing system / experimentation engine that can bill for money (presume the billing part).
The context of what problem you’re solving is secondary because it will change and evolve.
Today I would consider starting with:
- TryCelery - no presales, no demand
- Tailwind UI wireframe or PoC in HTML. Meant to be disposable. Shuffle.dev is a handy tool.
- Flutter to recreate and build the prototype, aloha and mvp to have one code hit to hit all platforms including web. Forget is generally newer and next green collated to it’s contemporaries.
Don’t work with tailwind or flutter? Hire a product designer and dev to not build it for you but teach you both via screen shares from UPWork, etc. If they can teach you how they can probably build it vs saying they can.
I agree with the comments saying you should use React. I always come back to it and never regret using it.
That said, there are some time killers you might not be anticipating up front (and this is true of basically whatever framework you use).
You will jump right past a ton of frustration and fatigue by using a starter template such as create-react-app, next.js's starter script, or remix.run's starter script. This saves you from so much config boilerplate, it's absolutely insane.
It's good to decide how the frontend and backend will communicate early on, which will inform the "starter template" decision. For example, if you know you need your API to be written in Go, it makes sense to use create-react-app in anticipation of a client-side only codebase. If you don't need an external API and would prefer to have a node server tightly integrated with your frontend code (which can be an enormous time saver) with all the bells and whistles (SSR, static rendering), next.js or remix would be appropriate. Of course, you can still choose to have a node server coupled with your app even if you plan to use an external API if you want things like SSR.
And keep in mind that even if you do use an external API, cookie-based authentication works just fine if the backend supports it (as with Django Rest Framework).
I typically end up using Django as a backend for the sane migrations, built-in auth, and extensible admin. I find the JavaScript ecosystem in general to be _fucking terrible_ when it comes to managing databases (though there is some ongoing work in this space), and I haven't found a real competitor to Django's auth or admin for early productivity literally anywhere.
Mull these things over for a while before you write any real code.
That said, there are some time killers you might not be anticipating up front (and this is true of basically whatever framework you use).
You will jump right past a ton of frustration and fatigue by using a starter template such as create-react-app, next.js's starter script, or remix.run's starter script. This saves you from so much config boilerplate, it's absolutely insane.
It's good to decide how the frontend and backend will communicate early on, which will inform the "starter template" decision. For example, if you know you need your API to be written in Go, it makes sense to use create-react-app in anticipation of a client-side only codebase. If you don't need an external API and would prefer to have a node server tightly integrated with your frontend code (which can be an enormous time saver) with all the bells and whistles (SSR, static rendering), next.js or remix would be appropriate. Of course, you can still choose to have a node server coupled with your app even if you plan to use an external API if you want things like SSR.
And keep in mind that even if you do use an external API, cookie-based authentication works just fine if the backend supports it (as with Django Rest Framework).
I typically end up using Django as a backend for the sane migrations, built-in auth, and extensible admin. I find the JavaScript ecosystem in general to be _fucking terrible_ when it comes to managing databases (though there is some ongoing work in this space), and I haven't found a real competitor to Django's auth or admin for early productivity literally anywhere.
Mull these things over for a while before you write any real code.
Prisma and NextAuth.js are first class modern Typescript replacements for Django’s ORM and auth respectively. Django’s only competitive advantage is its Admin and common convention.
Prisma is pretty good, but the migrations system doesn't really compare. If your answer to many (any?) migrations is "blow away the existing database", that's not gonna work for me. Another thing that's not gonna work for me is generating each migration by hand with SQL specific to the dialect that youre using in development, now that I'm spoiled with Django's auto-migrations. I've had good success with Prisma by using Django to simply manage the schema and using `prisma pull db` (though Prisma unfortunately errors if you are using the default type for primary keys, AutoBigInteger because it can't handle BigNumber). Prisma is basically the ORM I had in mind when I said "there has been work in this space", FYI.
I have only used NextAuth a tiny bit, but it wasn't clear to me how to, for example, extend the user model to add fields to users. I would appreciate it if you have any resources you could point me to for an example or explanation on how to achieve that. I also did not find documentation about how to add my own authentication adapter (or plugin or whatever language they use).
I have only used NextAuth a tiny bit, but it wasn't clear to me how to, for example, extend the user model to add fields to users. I would appreciate it if you have any resources you could point me to for an example or explanation on how to achieve that. I also did not find documentation about how to add my own authentication adapter (or plugin or whatever language they use).
Extend the User model in Prisma: https://github.com/t3-oss/create-t3-app/blob/main/cli/templa...
Here's the file you add auth "providers": https://github.com/t3-oss/create-t3-app/blob/main/cli/templa...
Custom providers: https://next-auth.js.org/configuration/providers/oauth#using...
Here's the file you add auth "providers": https://github.com/t3-oss/create-t3-app/blob/main/cli/templa...
Custom providers: https://next-auth.js.org/configuration/providers/oauth#using...
How does your random link to a Prisma schema relate to next-auth? Did that come from next-auth documentation?
Cool, how do I make a provider? That's pretty anemic documentation. I feel literally 0% more informed about the process. Obviously I could go through the fucking source code to find out how custom oauth providers were implemented!
But I don't care about oauth 99% of the time! What I actually want is username/password login with session cookies. How do I do that?
> The Credentials provider allows you to handle signing in with arbitrary credentials, such as a username and password, domain, or two factor authentication or hardware device (e.g. YubiKey U2F / FIDO).
> It is intended to support use cases where you have an existing system you need to authenticate users against.
What if I want session cookies instead of JWT? And there's no default schema (which is because it has no baked in ORM or database management, to be fair), so I have to go through the boilerplate of defining it in in every new project. And I'll have to figure out how to do permission based access and groups. This is all table stakes, for me. Next Auth isn't actually taking care of any of the hard parts of my use case.
It just doesn't have the bare minimum that I need it to have to be a suitable replacement.
Cool, how do I make a provider? That's pretty anemic documentation. I feel literally 0% more informed about the process. Obviously I could go through the fucking source code to find out how custom oauth providers were implemented!
But I don't care about oauth 99% of the time! What I actually want is username/password login with session cookies. How do I do that?
> The Credentials provider allows you to handle signing in with arbitrary credentials, such as a username and password, domain, or two factor authentication or hardware device (e.g. YubiKey U2F / FIDO).
> It is intended to support use cases where you have an existing system you need to authenticate users against.
What if I want session cookies instead of JWT? And there's no default schema (which is because it has no baked in ORM or database management, to be fair), so I have to go through the boilerplate of defining it in in every new project. And I'll have to figure out how to do permission based access and groups. This is all table stakes, for me. Next Auth isn't actually taking care of any of the hard parts of my use case.
It just doesn't have the bare minimum that I need it to have to be a suitable replacement.
Judging from your requirements for the app you're building - it sounds like maybe the core should be a typescript library handling the data and rendering - then wrapped in a (eg: react) component, wrapped in an app - similar to eg d3.js might be used?
That said, I've been trying to find a reasonable stack for our project at work - and I'm so far quite impressed with RedwoodJS - it appears to help with a lot of useful "opinions" - on testing, on styling and integration with storybook.
As this is a hobby project, I'd probably try to optimize the choice for fun/joy - so maybe clojurescript/reagent, maybe svelte, maybe elm - maybe even something like https://www.amber-lang.net/ (although, probably not...).
Finally, sounds like you will be wrangling some narly data structures (annotations on top of documents) - sounds like you might need "more" than just typescript for that - perhaps clojure is a good fit?
That said, I've been trying to find a reasonable stack for our project at work - and I'm so far quite impressed with RedwoodJS - it appears to help with a lot of useful "opinions" - on testing, on styling and integration with storybook.
As this is a hobby project, I'd probably try to optimize the choice for fun/joy - so maybe clojurescript/reagent, maybe svelte, maybe elm - maybe even something like https://www.amber-lang.net/ (although, probably not...).
Finally, sounds like you will be wrangling some narly data structures (annotations on top of documents) - sounds like you might need "more" than just typescript for that - perhaps clojure is a good fit?
I've written about this before but I think overall the biggest advantage of React is the ecosystem. It's not the cleanest, fastest, etc. but the size of the community alone makes it worth it.
So yes, I'd recommend React - it takes some time to get comfortable with it but the investment pays off when you can find a lot of snippets of code ready to be used and most of your questions will probably already have an answer online.
Another benefit is that there are very well-established UI frameworks/design systems (Material UI, Antd) with standard components that allow you to build something that "looks good" without you having to worry much about it.
And finally you'll get good TypeScript support with most of the tools in the ecosystem.
So yes, I'd recommend React - it takes some time to get comfortable with it but the investment pays off when you can find a lot of snippets of code ready to be used and most of your questions will probably already have an answer online.
Another benefit is that there are very well-established UI frameworks/design systems (Material UI, Antd) with standard components that allow you to build something that "looks good" without you having to worry much about it.
And finally you'll get good TypeScript support with most of the tools in the ecosystem.
> Does anyone still write plain JS?
Does anyone still use ts? I mean why would you use a scripted language transpiled to another language? I suspect there is a little experience with js hence the “fear” of dynamically typed vars. Just use vue and regular js. You’ll do just fine.
Does anyone still use ts? I mean why would you use a scripted language transpiled to another language? I suspect there is a little experience with js hence the “fear” of dynamically typed vars. Just use vue and regular js. You’ll do just fine.
I think you’ll find, as evidenced by many popular libraries moving to TS, that TS is incredibly popular and increasingly becoming the defacto way to write for the web
Wouldnt harm pointing to stats. I might be wrong, but from experience, js is more than enough.
Sometimes the best way to think about things is to imagine them from the perspective of 1 or 2 or 5 years down the road. React is good. Will it be 5 years down the road? A lot of people will say it is impossible to imagine, but you don't have to be right in your imagination, but rather diligent. What are the second order effects of your decisions?
For example, if you think you want to develop mobile apps at some point, making a good choice now that makes it difficult to do that later is perhaps not a good decision.
Then there is the question of skill sets. How many languages, technologies do you need to know? Javascript is good because it is pervasive. Terrible in many ways, (yes I'm looking at you null and this) but pervasive and most importantly improving.
Which leads us to velocity. Javascript has velocity right now. Both the improvements to the language and things like Deno. I've been using koa - not express - for years. and now there deno/oak appears likely to be a future stepping stone.
Then there is methodology. Depending on the scale of your project, the ability to make progress - as a sole or small team of developers - is vital. No progress === no product. (Love that Javascript requires three =). I don't use typescript because it inhibits my progress. I suspect that this is a personal thing. I would rather evolve code than write code (or perhaps right is the correct word). I do much better personally writing something, having it be wrong and re-writing it again. That is probably just me so your mileage may vary. The point is to know what is best for you. I am extremely opinionated not because I know what is correct, but because I know what works best for me.
I do have some danger signs. C# as much as I like the language is not a viable choice because it is company driven to a very great extent. Go is again the same as much as I am intrigued by it. Rust is very tempting if I had a need for it, and wasm makes it more interesting. But the learning curve is just more than I can handle while trying to actually accomplish things.
And I suppose that is the final issue: what is the time to market or product?
For example, if you think you want to develop mobile apps at some point, making a good choice now that makes it difficult to do that later is perhaps not a good decision.
Then there is the question of skill sets. How many languages, technologies do you need to know? Javascript is good because it is pervasive. Terrible in many ways, (yes I'm looking at you null and this) but pervasive and most importantly improving.
Which leads us to velocity. Javascript has velocity right now. Both the improvements to the language and things like Deno. I've been using koa - not express - for years. and now there deno/oak appears likely to be a future stepping stone.
Then there is methodology. Depending on the scale of your project, the ability to make progress - as a sole or small team of developers - is vital. No progress === no product. (Love that Javascript requires three =). I don't use typescript because it inhibits my progress. I suspect that this is a personal thing. I would rather evolve code than write code (or perhaps right is the correct word). I do much better personally writing something, having it be wrong and re-writing it again. That is probably just me so your mileage may vary. The point is to know what is best for you. I am extremely opinionated not because I know what is correct, but because I know what works best for me.
I do have some danger signs. C# as much as I like the language is not a viable choice because it is company driven to a very great extent. Go is again the same as much as I am intrigued by it. Rust is very tempting if I had a need for it, and wasm makes it more interesting. But the learning curve is just more than I can handle while trying to actually accomplish things.
And I suppose that is the final issue: what is the time to market or product?
The dev community seems to love to drop frameworks they don't love rather quickly, as a React guy I think this will happen to React too when something even a little bit better comes along.
Java is essentially dead for new projects, even though 5 years ago it was king.
People love Python so they keep it alive. I still see projects using Python/Django as the main backend in 2022.
As to Typescript, I think it focuses on the wrong problem so I agree with your thoughts there. Optional chaining fixes most issues what Typescript would solve.
Java is picked for new projects alle the time. Tho usually in the form of quarkus, micronauts, etc
If you want something that has tons of help, e.g. in stackoverflow, I'd recommend React. The next best framework seems to be Next.JS, that will come after React.
React has no performance issues at all, only for those who don't understand keys and how rendering works, or how to separate API calls for an async data flow.
Hot take, but imho, typescript is overrated, I can tell you how many times I had a TypeError on production in the past two years: exactly zero. There seem to be more obvious quality optimizations to me than typing.
To be totally clear, next.js is a React framework. The main draw (IMO) is having your frontend and backend written in the same language, plus it supports features like SSR and static site generation.
+1 for Nextjs. Productivity is really high when using Nextjs.
Deployment is a breeze too.
You can't go wrong with next.
I built a text annotation tool recently, first in React before rewriting it in Svelte. I found React's virtual DOM annoying, esp. when dealing with text selections + wrapping those selections with elements, etc. Svelte was just simpler in this regard (and overall, IMO).
But if you're not a frontend dev and want to use lots of off-the-shelf components, Svelte's ecosystem is much smaller than React's, so you won't have access to full-featured component libraries like MUI, Chakra, etc. Additionally, Typescript support is stronger in React (it's mostly there in Svelte, but lacking in some areas [1]).
For both React and Svelte I found XState helpful to manage annotator state. It might not be necessary if your app isn't terribly complex (in particular, Svelte's built-in stores can handle complex state well), but I've found it a good way to think about state+events and more confidently make changes as a result.
1 - https://github.com/sveltejs/svelte/issues/4701
But if you're not a frontend dev and want to use lots of off-the-shelf components, Svelte's ecosystem is much smaller than React's, so you won't have access to full-featured component libraries like MUI, Chakra, etc. Additionally, Typescript support is stronger in React (it's mostly there in Svelte, but lacking in some areas [1]).
For both React and Svelte I found XState helpful to manage annotator state. It might not be necessary if your app isn't terribly complex (in particular, Svelte's built-in stores can handle complex state well), but I've found it a good way to think about state+events and more confidently make changes as a result.
1 - https://github.com/sveltejs/svelte/issues/4701
I think it’s worth nothing that pretty much any vanilla js library works out of the box with svelte with very little extra effort. Don’t discount the size of that ecosystem
Here's the `modern` stack I would use. but before jumping to names directly, why modern and why not battle tested react-materialui or bootstrap? Because the stack I am explaining below 'actually' solves some major problems.
- If you care about SSR then definitely either NextJS or remix.run
- If SSR is not the priority then STAY AWAY FROM REACT. Creating the complicated UIs in react is easy, but refactoring is hard. React on a big project is like point free code with ramda or lodash/fp. you write code, compose and everything is working and then you realize you missed something, so you go back and check your entire UI is a chain of many smaller, intertwined components and it's too late to refactor now. Hooks and global state management (redux) is another huge mess
- So if not react then what? That you will have to evaluate yourself.
- Vue is notoriously popular in open source community, and have often proven to be a reliable framework, especially with Vue3 you get benefits of performance + DX both. whats wrong with vue? Lots of `this` usage, vue specific directives, directives are not expressions but strings.
- Angular is worst of all. bad docs, bad DX, extremely bloated. OOP oriented, I would stay away.
- Svelte? yeah it's like Vue + React child. A lot less intuitive than either. plus community is smaller than any other framework. what you get is only and only performance, comparable to Vue.
What stack I would use: - SolidJS (haven't used it, always wanted to try)
- If you are going with nextjs/remix/react Mantine-UI for components
- If you are going with React (CSR), chakraui with custom CSS. Good DX.
- Graphql + a lot of typescript ecosystem for large amount of codegen. the less you type it yourself the better
- If you care about SSR then definitely either NextJS or remix.run
- If SSR is not the priority then STAY AWAY FROM REACT. Creating the complicated UIs in react is easy, but refactoring is hard. React on a big project is like point free code with ramda or lodash/fp. you write code, compose and everything is working and then you realize you missed something, so you go back and check your entire UI is a chain of many smaller, intertwined components and it's too late to refactor now. Hooks and global state management (redux) is another huge mess
- So if not react then what? That you will have to evaluate yourself.
- Vue is notoriously popular in open source community, and have often proven to be a reliable framework, especially with Vue3 you get benefits of performance + DX both. whats wrong with vue? Lots of `this` usage, vue specific directives, directives are not expressions but strings.
- Angular is worst of all. bad docs, bad DX, extremely bloated. OOP oriented, I would stay away.
- Svelte? yeah it's like Vue + React child. A lot less intuitive than either. plus community is smaller than any other framework. what you get is only and only performance, comparable to Vue.
What stack I would use: - SolidJS (haven't used it, always wanted to try)
- If you are going with nextjs/remix/react Mantine-UI for components
- If you are going with React (CSR), chakraui with custom CSS. Good DX.
- Graphql + a lot of typescript ecosystem for large amount of codegen. the less you type it yourself the better
> it's too late to refactor now.
typescript effectively eliminates this issue, which is why it comes so highly recommended - regardless of framework.
vanilla javascript is not your friend on large, complex projects.
typescript effectively eliminates this issue, which is why it comes so highly recommended - regardless of framework.
vanilla javascript is not your friend on large, complex projects.
I've increased my productivity massively with Remix react (https://remix.run/docs/en/v1). You default to HTML and JS but extend it with JSX/React. It supports Markdown MDX out of the box. It has some architectural features that allows me to reduce my lines of code 60-90%. No more reducers, context, weird state bugs. Just do your work and be done. But you can use all of these or any third party react component if you want to.
There are three functions, your export default JSX, a "loader" which runs on every load, and "action" for GET/POST to handle mutations. From this, you get the old style CGI script work flow.
It has its own context via OutletContext that does away with react's state weirdness/gotcha's. My old code for stripe/mailchimp/oauth was 4000 lines. In remix, it's 400 lines.
For CSS I am using Material v5, but that wasn't my choice. Although I am a big fan of it's <Box display="flex" sx={{ maxWidth:'xyz', foo:bar }}>. I think "Box" has been copied from theme-ui (?), it seems universal in this era. With just <Box> and Markdown, I can make a nice website.
For testing, I use Playwright with Cucumber-js, but with a twist. I write my tests as acceptance criteria format but in markdown. I can embed documentation and images that are ignored by the test runner.
For the backend I use Postgraphile and roles with row level security. Remix serves a cookie and I store a JWT token to talk directly to postgresql. I get enterprise level response with graphql without having to write any graphql handlers.
It's the best stack I've ever used so far. If I could describe the experience in one sentence: "Get out of my way, so I can work done!"
There are three functions, your export default JSX, a "loader" which runs on every load, and "action" for GET/POST to handle mutations. From this, you get the old style CGI script work flow.
It has its own context via OutletContext that does away with react's state weirdness/gotcha's. My old code for stripe/mailchimp/oauth was 4000 lines. In remix, it's 400 lines.
For CSS I am using Material v5, but that wasn't my choice. Although I am a big fan of it's <Box display="flex" sx={{ maxWidth:'xyz', foo:bar }}>. I think "Box" has been copied from theme-ui (?), it seems universal in this era. With just <Box> and Markdown, I can make a nice website.
For testing, I use Playwright with Cucumber-js, but with a twist. I write my tests as acceptance criteria format but in markdown. I can embed documentation and images that are ignored by the test runner.
For the backend I use Postgraphile and roles with row level security. Remix serves a cookie and I store a JWT token to talk directly to postgresql. I get enterprise level response with graphql without having to write any graphql handlers.
It's the best stack I've ever used so far. If I could describe the experience in one sentence: "Get out of my way, so I can work done!"
For those recommending React: why not Vue? Not intending to be provocative so much as understanding where advocates see trade offs.
People tend to reply with what they know, and there’s no denying that React is incredibly popular. That said, pick any of the popular frameworks like React, Vue, Angular etc and it’ll be fine. There’s not really a huge difference between all of them.
Can't go wrong with TypeScript + React. You can use ViteJS to bootstrap your project and build an optimized version for production. VSCode for a good TypeScript developer experience. Recommend to check out React Router and React Query if you go with React.
I personally still use vanilla CSS instead of the many other alternatives. I keep 1 CSS file per page/component (e.g. directory "Home" > index.tsx + index.css) and add a class at the root of my page/component (e.g. <div className="home">) and then prefix every rule in this directory with this class (e.g. .home .something-inside-this-page). It keeps everything easily manageable and avoids CSS conflicts. Check out grid (vertical and horizontal layout) and flex (vertical or horizontal layout) if you are not familiar with these "modern" CSS features, they make everything simpler.
I personally still use vanilla CSS instead of the many other alternatives. I keep 1 CSS file per page/component (e.g. directory "Home" > index.tsx + index.css) and add a class at the root of my page/component (e.g. <div className="home">) and then prefix every rule in this directory with this class (e.g. .home .something-inside-this-page). It keeps everything easily manageable and avoids CSS conflicts. Check out grid (vertical and horizontal layout) and flex (vertical or horizontal layout) if you are not familiar with these "modern" CSS features, they make everything simpler.
I love Mithril (https://mithril.js.org), even in 2022. I wrote a blog about how/why I used it for Homechart:
https://homechart.app/blog/tech-stack-ui/
https://homechart.app/blog/tech-stack-ui/
I think go with Ionic and Angular. The ionic components are really great way to get acceptable UI running quickly and straight away you have a PWA even if you dont go down the iOS Android path. Angular is opinionated which is good. Less decisions to make. Lots of common questions are answered on Stack.
You may want to consider a meta-framework for the same reason I did.
I also code on my own. I was interested in building stuff, but had little time to learn everything I needed to from the bottom up to glue everything together.
Redwoodjs uses an opinionated rails-like approach to give you cli commands to generate your code to glue things together or to do the scaffolding required for the task at hand. The tech stack used is (subjectively) a good tech stack to work with: React, GraphQL, Prisma, Typescript, Jest and Storybook. To a large degree, due to the opinionated approach, at least you find yourself using what are considered to be good patterns.
If you do go the meta-framework approach, Redwoodjs has some competition in the space who are also well regarded and worth looking at.
I also code on my own. I was interested in building stuff, but had little time to learn everything I needed to from the bottom up to glue everything together.
Redwoodjs uses an opinionated rails-like approach to give you cli commands to generate your code to glue things together or to do the scaffolding required for the task at hand. The tech stack used is (subjectively) a good tech stack to work with: React, GraphQL, Prisma, Typescript, Jest and Storybook. To a large degree, due to the opinionated approach, at least you find yourself using what are considered to be good patterns.
If you do go the meta-framework approach, Redwoodjs has some competition in the space who are also well regarded and worth looking at.
Next.js (React framework), Tailwind CSS, NextAuth.js, React-Query (tanstack/query).
These are the current most well regarded and largest traction Typescript projects on the frontend.
Then, if you don’t need server-side state, your entire backend can be run from Next.js serverless and Prisma ORM.
These are the current most well regarded and largest traction Typescript projects on the frontend.
Then, if you don’t need server-side state, your entire backend can be run from Next.js serverless and Prisma ORM.
I switched from using React to using Elixir, Phoenix, and LiveView about a year ago and couldn't be happier. The code is easier to write (for me, anyway) and pages load a lot faster. It's also more friendly towards laptop batteries.
Liveview is just insanely fast to develop with and pick up.
If TypeScript is a given, I’ll recommend Vite for tooling as a few others have. It’s fast (uses ESBuild to compile), has good defaults (you likely won’t find yourself in config hell like with Webpack), and a good ecosystem. I’d also look at Vitest for testing, as it’s well integrated and roughly compatible with Jest so you can switch if needed.
React isn’t a bad choice, but you might find Preact a better choice. It’s compatible with much of the React ecosystem too, but especially with their recently released signals library you may find its state management easier to reason about than hooks.
React isn’t a bad choice, but you might find Preact a better choice. It’s compatible with much of the React ecosystem too, but especially with their recently released signals library you may find its state management easier to reason about than hooks.
IMO you really have no choice but to use React because of React Native. Also, since you are somewhat new to this domain, you want to stick with the pack. Doing so will give you access to limitless 3rd party tools, libraries, etc and community expertise.
There might be solutions for just web that are better in some ways, but React isn't a bad choice. Given your parameters I'd optimize entirely for the factors mentioned above + dev velocity (Svelt's performance for example, rarely actually matters compared to community, ecosystem, react native, etc that React provides).
There might be solutions for just web that are better in some ways, but React isn't a bad choice. Given your parameters I'd optimize entirely for the factors mentioned above + dev velocity (Svelt's performance for example, rarely actually matters compared to community, ecosystem, react native, etc that React provides).
I am a React guy, but I can only see React or Angular meeting your needs
- Both are well-established, with lots of guides. Angular is much more "batteries included" and opinionated though - Both have good TS support, although React's might be slightly better I think Angular closed the gap sufficiently - Both have the most tooling - Both are the only likely candidates for "10 years maintenance" - I don't see why you'd want to do a truly native app but if Cordova doesn't work for your needs I guess React Native is a plus
Good luck
- Both are well-established, with lots of guides. Angular is much more "batteries included" and opinionated though - Both have good TS support, although React's might be slightly better I think Angular closed the gap sufficiently - Both have the most tooling - Both are the only likely candidates for "10 years maintenance" - I don't see why you'd want to do a truly native app but if Cordova doesn't work for your needs I guess React Native is a plus
Good luck
Don't write your own text editor. Just go pick TinyMCE or CKEditor, use their comment plugins and change tracking for your annotations, and wrap it up in whatever basic CRUD you want to make it into your app.
I know the phrase "build vs. buy" annoys people, but your use case is quite well solved by existing tools, so buy the hard parts and build the easy (CRUD) parts. If you succeed with a product, you can always re-build the editors later when it makes sense. (If it ever does.)
I know the phrase "build vs. buy" annoys people, but your use case is quite well solved by existing tools, so buy the hard parts and build the easy (CRUD) parts. If you succeed with a product, you can always re-build the editors later when it makes sense. (If it ever does.)
Use whatever you like. Is a spare time project, you don't want the tool be an excuse to not start right now. The end user doesn't give a shit about minimal performance wins.
Just pick a framework and make it work.
It sounds like you should spend the bulk of your time instead on figuring out how the text annotation portion will work - the framework will be secondary or even tertiary to being able to annotate the text and saving and retrieving the annotations.
Copy a lot from the other websites, ex: medium.com does this annotation, yeah? (side question, why not blog on medium and leverage the annotations there?)
It sounds like you should spend the bulk of your time instead on figuring out how the text annotation portion will work - the framework will be secondary or even tertiary to being able to annotate the text and saving and retrieving the annotations.
Copy a lot from the other websites, ex: medium.com does this annotation, yeah? (side question, why not blog on medium and leverage the annotations there?)
I know it may look like an odd recommendation, but if you are comfortable with Java, look at Vaadin: It allows you to write "everything" in Java, and indeed without any care for client-server separation/communication/whatever; Just like you would write a GUI in Swing or JavaFX.
For Python there are Streamlit and Dash amon others. For other languages maybe too, but I'm not aware of them.
For Python there are Streamlit and Dash amon others. For other languages maybe too, but I'm not aware of them.
I built an app with Vue, then regretted it. React has the mindshare. I'd recommend going with that for that reason (especially React Native).
Use React unless you have a reason not to do so.
Check your local developer market and find what most people already know and use that. choosing a stack is not so much about -the right- library but the one that makes the most sense to the people that you will work with.
that said, you will be able to buy templates much more easily for the bigger frameworks.
that said, you will be able to buy templates much more easily for the bigger frameworks.
If it were up to me, I'd go with the following (mostly based on the largest communities):
- Typescript
- React
- styled-components (I've heard good things about tailwindcss too)
- Jest and react-testing-library for testing
- prettier and eslint for linting
Just throwing it out there in case you'd like to share your code between web, desktop and mobile:
- Electron (desktop)
- React-Native (mobile)
- React-native-web (to bridge it all together)
- Typescript
- React
- styled-components (I've heard good things about tailwindcss too)
- Jest and react-testing-library for testing
- prettier and eslint for linting
Just throwing it out there in case you'd like to share your code between web, desktop and mobile:
- Electron (desktop)
- React-Native (mobile)
- React-native-web (to bridge it all together)
These are good suggestions. I would be wary of picking something like styled-components upfront, though. If you're using something like Chakra-UI or MUI 5 (my personal favorite), they might use different styling conventions in their docs and you may just find it easier to use whatever they use.
I think dotnet core with blazor is a good option these days.
- C# can be used for all code, frontend and backend.
- Several GUI frameworks/toolkits to choose from (mudblazor, radzen etc)
- Cross-platform
- High quality development tools from several providers
- Code can later be reused in native applications for most platforms
- Lots of documentation and tutorials available.
- C# can be used for all code, frontend and backend.
- Several GUI frameworks/toolkits to choose from (mudblazor, radzen etc)
- Cross-platform
- High quality development tools from several providers
- Code can later be reused in native applications for most platforms
- Lots of documentation and tutorials available.
Just want to comment that I strongly disagree with all the commenters recommending no framework at all. If you want to make badass modern software, you need to invest in learning a framework that will help you do that. React has a learning curve and there are gotchas if you don't take the time to internalize a solid mental model of how it works (reading docs, watching lots of youtube videos over lunch, shooting yourself in the foot many times, etc) - but in the end it is insane the number of problems it solves for you compared to just writing stuff from scratch. I was a FE dev in 2009, I remember the before-times, and I remember backbone, Dojo, etc that were all hot garbage. The expressive power of React (and other modern frameworks) and velocity that is possible is insane compared to writing everything with just js.
* Also note, this isn't just about react vs Vue (for example). You'll have to make like 20 tooling choices here.
* Also note, this isn't just about react vs Vue (for example). You'll have to make like 20 tooling choices here.
React with MUI is probably the "safe" choice right now. Getting good performance out of React when you have a lot of things updating in real time can be tricky but it sounds like you probably wouldn't run into that right away in an app like this.
We picked react with mui and indeed have many performance issues; we redid a part with tailwind and vanilla js en the difference in perf is quite bizar. But indeed more (a lot more) work.
Yeah if you want good performance out of a non-trivial React app you need to carefully consider memoization. It can become quite tedious making sure you've memoized the right things at the right places.
MUI also can be slow if you put dynamic stuff in the sx component property. Tailwind has the very nice property that there's no dynamic CSS generation at runtime.
MUI also can be slow if you put dynamic stuff in the sx component property. Tailwind has the very nice property that there's no dynamic CSS generation at runtime.
Don't choose the fronted framework, let it choose you based on your requirements.
Blazor WebAssembly might be your pick, there's a starting template, write the front-end in c# and everything else in HTML and CSS as usual.
It's such a breeze developing even complex webapps with it like my project collanon.app
It's such a breeze developing even complex webapps with it like my project collanon.app
So I checked out your project and the initial load is a bit slow. It's storing 26.1 MB of data so maybe that's why. Is it bringing the .NET CLR to the client?
I'd choose Bootstrap to start. Because with Bootswatch you get something decent looking out of the box.
For JS, I would either go for CycleJS, because observables are your friend in really complex UIs
For JS, I would either go for CycleJS, because observables are your friend in really complex UIs
- Webpack or Vite to build
- Forget Typescript. That’s for library code.
- Just use React.
- MobX or Redux for state management
- React Router for routing
- Chakra/Tailwind et. al for components and CSS-in-JS
- Auth0 for auth and you’ve got a full front end stack
Madness averted. Thank me later.
- Forget Typescript. That’s for library code.
- Just use React.
- MobX or Redux for state management
- React Router for routing
- Chakra/Tailwind et. al for components and CSS-in-JS
- Auth0 for auth and you’ve got a full front end stack
Madness averted. Thank me later.
Nextjs + React.
Typescript support, strong community, plenty of Jobs in the extreme case something happens.
This is coming from a Vuejs fan. I still use it but I switched to Nextjs and I don't regret it.
Typescript support, strong community, plenty of Jobs in the extreme case something happens.
This is coming from a Vuejs fan. I still use it but I switched to Nextjs and I don't regret it.
- Kotlin/JS
- Kotlin serialization
- Unified datamodel for frontend/backend
- Interfaces across platforms
Run it native (GraalVM) or JVM on the server, JS in the browser.
Run it native (GraalVM) or JVM on the server, JS in the browser.
I honestly can't say enough good stuff about the Kotlin Multiplatform system. You can use your React. You can bring MUI, so it's pretty by default, and animations / UI are really smooth.
Because of Kotlin Serialization, you can speak Protobuf or JSON really easily with Kotlin data classes, across platform boundaries.
Kotlin Coroutines support means your implementation code can work on top of ListenableFuture on the JVM or Promise in the browser.
It's just great. Very likely to be maintained, and even improved greatly, over the next 10 years, as it is the basis of Jetbrains' own business.
Because of Kotlin Serialization, you can speak Protobuf or JSON really easily with Kotlin data classes, across platform boundaries.
Kotlin Coroutines support means your implementation code can work on top of ListenableFuture on the JVM or Promise in the browser.
It's just great. Very likely to be maintained, and even improved greatly, over the next 10 years, as it is the basis of Jetbrains' own business.
out of curiosity, question from someone who has never ever done frontend.
to me, ember js seemed to be a good alternative a while back, and what i read about their approach seemed very reasonable. but no one ever talks about it, basically ever.
is it just that niche or simply no longer relevant? the community on the page seems to deliver quite happily ...
to me, ember js seemed to be a good alternative a while back, and what i read about their approach seemed very reasonable. but no one ever talks about it, basically ever.
is it just that niche or simply no longer relevant? the community on the page seems to deliver quite happily ...
Who are your customers?
What platforms do you think would be the most useful for them? A website or a mobile app or a desktop app?
What platforms do you think would be the most useful for them? A website or a mobile app or a desktop app?
Imba and nothing else comes even close
I've heard of this. How do you compare it to Nextjs, Astro, etc..
I would go with Angular.
Build a PWA until you need to go native.
Pick any UI framework that you like - Material, PrimeNG, Covalent...
Build a PWA until you need to go native.
Pick any UI framework that you like - Material, PrimeNG, Covalent...
frontend
- react or svelte
- preact or raw html/css/js if it's simple
backend
- go or python (go std lib is faster but harder to write complex queries in since the extant query builders/orms aren't as mature, django is easy and scales across a team)
- maybe node or deno if you prefer js syntax
- react or svelte
- preact or raw html/css/js if it's simple
backend
- go or python (go std lib is faster but harder to write complex queries in since the extant query builders/orms aren't as mature, django is easy and scales across a team)
- maybe node or deno if you prefer js syntax
The ionic framework is amazing for cross platform work. Strongly recommend.
If you want an iPhone and an android app, then look at Framework7.io
antd worked well for me
Web text editing is broken in mobile no? I would at first thinking on builing on prosemirror but it works imperfectly on mobile so I would choose native instead
Try Blazor Server - No JS.
[deleted]
> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.
Can you elaborate a bit more on this part, please? Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.
I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).
In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.
In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast (especially the parts of about "abstract syntax trees"), along with their open-source editor: https://github.com/datocms/structured-text
That's one possible to way to deal with complex annotated text.
A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor
I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.
Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.
Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).
Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.
---------
Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)
Have fun! Sounds like a cool project.
Can you elaborate a bit more on this part, please? Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.
I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).
In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.
In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast (especially the parts of about "abstract syntax trees"), along with their open-source editor: https://github.com/datocms/structured-text
That's one possible to way to deal with complex annotated text.
A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor
I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.
Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.
Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).
Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.
---------
Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)
Have fun! Sounds like a cool project.
[deleted]
eenie meenie miney mo
Svelet is great
They are all a waste of time.
The important thing is that they waste users' time and not the time of the developer(s).
Steve Jobs was aware of that.
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" [1]
[1]: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" [1]
[1]: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
Yes simultaneously thousands of developers are wrong and stupid and have no idea what they are doing, yet you are the enlightened one. Give me a break.
I just said its a waste of thier time. I didnt say they were stupid. You know how many devs have been deprecated in the past year? Millions. Tommorow there will be more, its just how the tools chain swings.
> Does anyone still write plain JS?
Oh yeah. JSDoc for type docs has saved me a ton of time fighting with Typescript. I also just think TS is ugly and verbose and personally don’t care for using it.
With FE JS I am usually using types to define the params/returns of functions, or defining the shape of an object to avoid unexpected undefineds.
With JSDoc you get IDE diagnostics for your types when defined without having to appease TS’ particular rules.
For your answer I genuinely suggest running through the intro docs for a few of them to see what clicks.
Vue is alright. React is okay.
If you’re keen to learn a new language and/or have Lisp experience, ClojureScript and re-frame are a pleasure to work with
Oh yeah. JSDoc for type docs has saved me a ton of time fighting with Typescript. I also just think TS is ugly and verbose and personally don’t care for using it.
With FE JS I am usually using types to define the params/returns of functions, or defining the shape of an object to avoid unexpected undefineds.
With JSDoc you get IDE diagnostics for your types when defined without having to appease TS’ particular rules.
For your answer I genuinely suggest running through the intro docs for a few of them to see what clicks.
Vue is alright. React is okay.
If you’re keen to learn a new language and/or have Lisp experience, ClojureScript and re-frame are a pleasure to work with
Then you will write a ton of unit tests, read them and realize: "all these type checks are exactly what TypeScript is doing".
Typescript doesn’t make sense if you don’t manipulate a lot of data or around the app. It can be a pain and lead to a lot of fatigue if don’t get benefits out of it. I am still using js for most of my personal front end projects, and still benefits from intellisense from libraries written in typescript even in standard .js file with VSCode and other IDEs. But 100% of my project uses Eslint (with « recommended » rules + eslint-config-prettier), this is absolutely a must have.
I very strongly disagree with this. Typescript is a lifesaver on a non-trivial React codebase. Writing correct code is hard and you need every advantage you can muster. Type checking is an important part of that.
Look into nullish coalescing and optional chaining.
Sure, vanilla JS or react doesn't help with using a var as a function, but I can probably count on my left hand how many times I tried to do that. That doesn't warrant a completely new language.
ps.: typeof is also a thing in vanilla JS
I have been writing TS all day every day for the last 5 years. I'm aware of null coalescing and optional chaining.
Every time people tell me "I just don't make type errors" I look through their issue tracker and find them everywhere.
Every time people tell me "I just don't make type errors" I look through their issue tracker and find them everywhere.
Totally agree, for non trivial project it totally makes sens, but for hobby project it doesn’t always make sens. Even less for beginners like OP.
That "pain and fatigue" is saving you from future bugs you'll inevitably pay for down the line.
Forcing you to be clear and explicit about types and handling cases where "undefined" could exist is a good thing.
It might take longer to develop but I've definitely seen I get fewer run time errors once it builds. No more staring at a blank page and checking the developer console for an undefined that's brought everything to a halt.
Forcing you to be clear and explicit about types and handling cases where "undefined" could exist is a good thing.
It might take longer to develop but I've definitely seen I get fewer run time errors once it builds. No more staring at a blank page and checking the developer console for an undefined that's brought everything to a halt.
I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.
Some notes about my needs:
- This would be by far the most complex GUI I've ever built.
- Relatedly, I expect to get the UX design horribly horribly wrong and start from scratch at least once.
- I also suck at making things look pretty and also don't find this problem very rewardinging to think or read about.
- All of the above point towards a framework that is pretty easy to get started in and prototype quickly.
- Because of limited time, and low confidence in UX design decisions, I would often follow the path of least resistance and the end product would be heavily influenced by the tools I used to build it.
----
- Despite what I said about quick rampup I'm fine with learning new languages.
- Weak typing is a deal-breaker. If using JS, must have good TypeScript integration or similar. (Does anyone still write plain JS?)
------
- I don't think I'll want a native desktop app but an iOS/Android version could make sense. But I'll never have time if this can't share most of the code with the web version.
-------
- I don't really have the discipline for manual testing. Luckily I also find it satisfying to over-invest in test automation. I don't really know how this is done in frontend land but good tooling would be a big plus.
-----
- I'm happy to sacrifice one or more of the other requirements in favour of tools that are likely to be maintained 10 years from now.
----
What are HNs thoughts?