Live data from Hacker News

Ask HN: Help me pick a front-end framework

news.ycombinator.com

101–110 of 181 posts

Re: Ask HN: Help me pick a front-end framework

#102
post #96

Earlier quoted context omitted.

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 ab…

I love Svelte and SvelteKit but if you're just interested in building your app, please pick something else for now. It's still constantly changing and while it's good it's being developed rapidly, it's definitely not something you want to spend your limited time on migrating while you could just be productive with say React. Okay sure, they have had big breaking changes in-between major versions as well, but before S…

This is definitely worth noting. SveleteKit is probably close to 1.0, but the current versioning strategy is incrementing one number, and those changes are always expected to be breaking (even if they aren’t frequently breaking).

That said, if you start working on a given pre-release and only upgrade to 1.0, the migration shouldn’t be too painful.

Re: Ask HN: Help me pick a front-end framework

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

Re: Ask HN: Help me pick a front-end framework

#105
post #31

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 al…

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

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.

Re: Ask HN: Help me pick a front-end framework

#106

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 su…

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

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

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

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

This might be most appropriate for the OP:

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

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

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

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

Re: Ask HN: Help me pick a front-end framework

#107
> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.

Can you elaborate a bit more on this part, please? Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.

I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).

In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.

In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast (especially the parts of about "abstract syntax trees"), along with their open-source editor: https://github.com/datocms/structured-text

That's one possible to way to deal with complex annotated text.

A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor

I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.

Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.

Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).

Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.

---------

Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)

Have fun! Sounds like a cool project.

Re: Ask HN: Help me pick a front-end framework

#108
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?

Re: Ask HN: Help me pick a front-end framework

#110

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 poin…

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…

Java is picked for new projects alle the time. Tho usually in the form of quarkus, micronauts, etc
Post reply on HN