Help me pick a front-end framework

Question

Hopefully this can be a fruitful discussion since I think I have a quite clear but also reasonably common set of needs. I have a feeling that if you're "in the world" of frontend engineering you get a much more intuitive feeling for these tooling questions than I can get at a distance by reading SEO-spam developer blogs and State Of JS (although the latter does seem really helpful).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?

chaos_emergent · Accepted Answer

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!

ryukoposting · Answer

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.

eric4smith · Answer

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.

vladstudio · Answer

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/

oblak · Answer

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. 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.

franciscop · Answer

> "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 or 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

zkirill · Answer

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 "" compared to fighting with module bundler du jour.

ajjenkins · Answer

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&rsquo;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&rsquo;t use HTML or real CSS (although it&rsquo;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&rsquo;t need to maintain multiple versions of your code.If you don&rsquo;t like React Native for some reason (e.g., it&rsquo;s made by Meta), you can also look into Flutter which is made by Google.

xrd · Answer

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...

snowstormsun · Answer

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).

gampleman · Answer

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&rsquo;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 &ldquo;front-end&rdquo;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&rsquo;t expect to have any influence on the direction or pace of Elm as such, you&rsquo;ll be happy.

enumjorge · Answer

OP, I didn&rsquo;t grok the description of what you&rsquo;re trying to build enough to have a useful suggestion for you, but as a word of caution you&rsquo;re probably going to get a lot of responses that don&rsquo;t take into account you&rsquo;re specific situation but instead are based on the commenter&rsquo;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.

tiborsaas · Answer

> Does anyone still write plain JSYes, 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.

miedpo · Answer

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.

pabe · Answer

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.

iambateman · Answer

I&rsquo;ll recommend two paths&hellip;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&rsquo;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&rsquo;t like react, but it&rsquo;s going to dominate front-end for the next five years at least.Best of luck!

ysavir · Answer

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.

antonpirker · Answer

"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!

Frotag · Answer

> 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).

mkarliner · Answer

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

Sladik · Answer

I find Vue easier to learn than React and its documentation is great.

WA · Answer

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.

pshc · Answer

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.

transfire · Answer

Elm on Taurihttps://dev.to/jxxcarlson/making-an-elm-desktop-app-with-tau...

dham · Answer

> text annotation appYou 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.

j45 · Answer

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&rsquo;t as bad idea. It will shed a light on where you wanna be with your final tech stack anyways. Customers generally don&rsquo;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&rsquo;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&rsquo;s contemporaries.Don&rsquo;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.

DangitBobby · Answer

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.

e12e · Answer

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?

yakkomajuri · Answer

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.

yrgulation · Answer

> 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 &ldquo;fear&rdquo; of dynamically typed vars. Just use vue and regular js. You&rsquo;ll do just fine.

talkingtab · Answer

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?

ricardobayes · Answer

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.

licyeus · Answer

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

Sparkenstein · Answer

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

fswd · Answer

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 . I think "Box" has been copied from theme-ui (?), it seems universal in this era. With just 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!"

poulsbohemian · Answer

For those recommending React: why not Vue? Not intending to be provocative so much as understanding where advocates see trade offs.

ggregoire · Answer

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. ) 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.

candiddevmike · Answer

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/

farmin · Answer

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.

stuzenz · Answer

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.

reducesuffering · Answer

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&rsquo;t need server-side state, your entire backend can be run from Next.js serverless and Prisma ORM.

innocentoldguy · Answer

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.

eyelidlessness · Answer

If TypeScript is a given, I&rsquo;ll recommend Vite for tooling as a few others have. It&rsquo;s fast (uses ESBuild to compile), has good defaults (you likely won&rsquo;t find yourself in config hell like with Webpack), and a good ecosystem. I&rsquo;d also look at Vitest for testing, as it&rsquo;s well integrated and roughly compatible with Jest so you can switch if needed.React isn&rsquo;t a bad choice, but you might find Preact a better choice. It&rsquo;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.

eagsalazar2 · Answer

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).

nawgz · Answer

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 plusGood luck

codingdave · Answer

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.)

adabaed · Answer

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.

bfung · Answer

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?)

theanonymousone · Answer

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.

nprateem · Answer

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).

revskill · Answer

Use React unless you have a reason not to do so.

jhoelzel · Answer

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.

sakerbos · Answer

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 lintingJust 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)

carapace · Answer

ELM!!! https://elm-lang.org/

Kon5ole · Answer

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.

eagsalazar2 · Answer

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.

cageface · Answer

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.

bamboozled · Answer

Don't choose the fronted framework, let it choose you based on your requirements.

thepra · Answer

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

k__ · Answer

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

ramesh31 · Answer

- Webpack or Vite to build- Forget Typescript. That&rsquo;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&rsquo;ve got a full front end stackMadness averted. Thank me later.

elforce002 · Answer

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.

sgammon · Answer

- Kotlin/JS - Kotlin serialization - Unified datamodel for frontend/backend - Interfaces across platformsRun it native (GraalVM) or JVM on the server, JS in the browser.

flypenguin · Answer

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 ...

andsoitis · Answer

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?

ilrwbwrkhv · Answer

Imba and nothing else comes even close

r0b05 · Answer

I would go with Angular.Build a PWA until you need to go native.Pick any UI framework that you like - Material, PrimeNG, Covalent...

jd3 · Answer

frontend- react or svelte- preact or raw html/css/js if it's simplebackend- 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

mchusma · Answer

The ionic framework is amazing for cross platform work. Strongly recommend.

sroussey · Answer

If you want an iPhone and an android app, then look at Framework7.io

chimen · Answer

antd worked well for me

polote · Answer

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

sanatgersappa · Answer

Try Blazor Server - No JS.

solardev · Answer

> 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-textThat'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-editorI 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.

drbojingle · Answer

eenie meenie miney mo

mindaslab · Answer

Svelet is great

32gbsd · Answer

They are all a waste of time.

butterfly771 · Answer

Obviously React

nucleogenesis · Answer

> 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&rsquo;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&rsquo; 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&rsquo;re keen to learn a new language and/or have Lisp experience, ClojureScript and re-frame are a pleasure to work with

blaydator · Answer

Typescript doesn&rsquo;t make sense if you don&rsquo;t manipulate a lot of data or around the app. It can be a pain and lead to a lot of fatigue if don&rsquo;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 &laquo; recommended &raquo; rules + eslint-config-prettier), this is absolutely a must have.

Help me pick a front-end framework

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/

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/