13 ms·

Ask HN: Help me pick a front-end framework

• chimen 4y ago
  antd worked well for me
• 32gbsd 4y ago
  They are all a waste of time.
  • RunSet 4y ago
    The important thing is that they waste users' time and not the time of the developer(s).
    • cube00 4y ago
      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 https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
  • matthewwolfe 4y ago
    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.
    • 32gbsd 4y ago
      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.
• dham 4y ago
  > 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.
• polote 4y ago
  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
• butterfly771 4y ago
  Obviously React
  • alexvoda 4y ago
    More details about the reasons would be helpful.
• cageface 4y ago
  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.
  • tluyben2 4y ago
    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.
    • cageface 4y ago
      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.
• candiddevmike 4y ago
  I love Mithril (https://mithril.js.org 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/
• iambateman 4y ago
  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!
  • gremlinsinc 4y ago
    There's also livewire plus filament admin on the backend. Makes coding a breeze.
• deleted 4y ago
  [deleted]
• mkarliner 4y ago
  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
• chaos_emergent 4y ago
  Sounds like you're in a similar place as me a year ago. Here's a list of tools that I'd use: - TypeScript for language. Gives you an insanely expressive type system that is a step up from Python duck typing (which you seem familiar with after perusing your GH). - React for framework. Frontend experts will shit on it for being non-performant or having a poor UX, but the community is massive and you'll have a ton of support both in terms of people that can help you when you're stuck and libraries that do a lot of work for you. - Jest for code testing and Cypress for integration testing. The obvious tools for the job. - Chakra UI for a UI framework. Has all the bells and whistles, DX is great, and there are plenty of escape hatches for non-default behavior. - TipTap for text editor. This is the _most_ at risk of not being supported in 10 years, but I still see it as a low risk because they have a solid monetization strategy in place. - Electron for the desktop app. If you _really_ don't want to use Electron then use Tauri (what we use at my company). It uses the native browser engine so package sizes are ridiculously small and it's insanely performant. - Don't worry about the mobile apps for now. At the very most, just make it a web app that has responsive theming for mobile. Good luck and have fun!
  • lucas_codes 4y ago
    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 https://developer.mozilla.org/en-US/docs/Web/API/Selection
    • chaos_emergent 4y ago
      Ah, good point, TipTap may be overkill if OP doesn’t want to edit it at all.
  • Aldo_MX 4y ago
    For the mobile apps the missing piece of the puzzle is Capacitor. Also, look for React Testing Library to complement Jest.
• blaydator 4y ago
  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.
  • cageface 4y ago
    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.
    • ricardobayes 4y ago
      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
      • cageface 4y ago
        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.
    • blaydator 4y ago
      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.
  • cube00 4y ago
    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.
• adabaed 4y ago
  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.
• Sladik 4y ago
  I find Vue easier to learn than React and its documentation is great.
  • rhengles 4y ago
    +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 https://github.com/arijs/vitesse-modular-naiveui
• enumjorge 4y ago
  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.
  • aaaaaaaaata 4y ago
    How fast can I do the least work? React. Never "how can I do the most maintainable code", "how can I write good code".
• transfire 4y ago
  Elm on Tauri https://dev.to/jxxcarlson/making-an-elm-desktop-app-with-tauri-3n3i https://dev.to/jxxcarlson/making-an-elm-desktop-app-with-tau...
• revskill 4y ago
  Use React unless you have a reason not to do so.
• ajjenkins 4y ago
  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.
• eric4smith 4y ago
  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.
  • klabb3 4y ago
    > 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.
    • cube00 4y ago
      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.
    • jefftk 4y ago
      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.
      • _gabe_ 4y ago
        > 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 ;)
• Frotag 4y ago
  > 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).
  • mattlondon 4y ago
    +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.
• r0b05 4y ago
  I would go with Angular. Build a PWA until you need to go native. Pick any UI framework that you like - Material, PrimeNG, Covalent...
• zkirill 4y ago
  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.
• snowstormsun 4y ago
  I would suggest you to take a look at https://svelte.dev/ 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).
  • whiddershins 4y ago
    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.
    • kevinak 4y ago
      No more dealing with SvelteKit changes, we've hit RC! :)
• sakerbos 4y ago
  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)
  • DangitBobby 4y ago
    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.
• Kon5ole 4y ago
  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.
• pshc 4y ago
  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.
  • BatFastard 4y ago
    Second the recommendation for Flutter, very robust dev environment.
• xrd 4y ago
  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...
  • xrd 4y ago
    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.
• ryukoposting 4y ago
  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.
  • danbulant 4y ago
    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.
• ysavir 4y ago
  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.
  • gushogg-blake 4y ago
    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.
• carapace 4y ago
  ELM!!! https://elm-lang.org/ https://elm-lang.org/
• deleted 4y ago
  [deleted]
• farmin 4y ago
  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.
• talkingtab 4y ago
  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 4y ago
    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.
• pabe 4y ago
  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.
• tiborsaas 4y ago
  > 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.
• yakkomajuri 4y ago
  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.
• nucleogenesis 4y ago
  > 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
  • 29athrowaway 4y ago
    Then you will write a ton of unit tests, read them and realize: "all these type checks are exactly what TypeScript is doing".
• mindaslab 4y ago
  Svelet is great
• oblak 4y ago
  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.
• nprateem 4y ago
  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).
• ricardobayes 4y ago
  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.
  • DangitBobby 4y ago
    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.
  • elforce002 4y ago
    +1 for Nextjs. Productivity is really high when using Nextjs. Deployment is a breeze too. You can't go wrong with next.
• drbojingle 4y ago
  eenie meenie miney mo
• bxjf 4y ago
• andsoitis 4y ago
  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?
• DangitBobby 4y ago
  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.
  • reducesuffering 4y ago
    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.
    • DangitBobby 4y ago
      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).
• ramesh31 4y ago
  - 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.
• poulsbohemian 4y ago
  For those recommending React: why not Vue? Not intending to be provocative so much as understanding where advocates see trade offs.
  • matthewwolfe 4y ago
    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.
• franciscop 4y ago
  > "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 https://github.com/franciscop/modern-editor [2] https://answerly.io/blog/my-pain-developing-a-wysiwyg-editor-with-contenteditable/ https://answerly.io/blog/my-pain-developing-a-wysiwyg-editor... [3] https://news.ycombinator.com/item?id=27938702 https://news.ycombinator.com/item?id=27938702 [4] https://stackoverflow.com/q/4495626/938236 https://stackoverflow.com/q/4495626/938236
  • eagsalazar2 4y ago
    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.
• Sparkenstein 4y ago
  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
  • munbun 4y ago
    > 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.
• ilrwbwrkhv 4y ago
  Imba and nothing else comes even close
  • elforce002 4y ago
    I've heard of this. How do you compare it to Nextjs, Astro, etc..
• antonpirker 4y ago
  "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!
  • IshKebab 4y ago
    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.
  • temeritatis 4y ago
    > 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.
• elforce002 4y ago
  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.
• reducesuffering 4y ago
  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.
• thepra 4y ago
  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
  • r0b05 4y ago
    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?
• miedpo 4y ago
  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.
  • klysm 4y ago
    > 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.
    • hunterb123 4y ago
      It's also not true, React can be used with a single script tag
      • ipaddr 4y ago
        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
    • miedpo 4y ago
      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.
  • 4y ago
• sroussey 4y ago
  If you want an iPhone and an android app, then look at Framework7.io
• solardev 4y ago
  > 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 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 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 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 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.
• e12e 4y ago
  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/ 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?
• vladstudio 4y ago
  As in every post about front-end frameworks, I must mention HTMX and Unpoly: https://htmx.org/ https://htmx.org/ https://unpoly.com/ https://unpoly.com/ To learn more about the concept, please take a look at Essays here: https://htmx.org/essays/ https://htmx.org/essays/
  • everybodyknows 4y ago
    Is Unpoly alternative to HTMX? Or could the two be complementary?
    • vladstudio 4y ago
      they are alternatives, not complementary. Unpoly seems to include more features, layers are particularly impressive.
• ggregoire 4y ago
  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.
• eagsalazar2 4y ago
  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 4y ago
  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
• eagsalazar2 4y ago
  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.
• bfung 4y ago
  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?)
• mchusma 4y ago
  The ionic framework is amazing for cross platform work. Strongly recommend.
• WA 4y ago
  Maybe have a look at Stencil (+ Ionic). https://stenciljs.com/ 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.
• eyelidlessness 4y ago
  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.
• stuzenz 4y ago
  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.
• yrgulation 4y ago
  > 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.
  • matthewwolfe 4y ago
    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
    • yrgulation 4y ago
      Wouldnt harm pointing to stats. I might be wrong, but from experience, js is more than enough.
• innocentoldguy 4y ago
  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.
  • jnsaff2 4y ago
    Liveview is just insanely fast to develop with and pick up.
• fswd 4y ago
  I've increased my productivity massively with Remix react (https://remix.run/docs/en/v1 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!"
• bamboozled 4y ago
  Don't choose the fronted framework, let it choose you based on your requirements.
• k__ 4y ago
  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
• theanonymousone 4y ago
  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.
• codingdave 4y ago
  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.)
• sgammon 4y ago
  - 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.
  • sgammon 4y ago
    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.
• licyeus 4y ago
  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 https://github.com/sveltejs/svelte/issues/4701
  • cpfohl 4y ago
    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
• jd3 4y ago
  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
• j45 4y ago
  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.
• gampleman 4y ago
  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.
• sanatgersappa 4y ago
  Try Blazor Server - No JS.
• jhoelzel 4y ago
  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.
• flypenguin 4y ago
  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 ...