Earlier quoted context omitted.
For prototyping and simple things, instead of mirroring my state in the DOM, I use the DOM to store state. Yes, it isn't quite as performant, but for this sort of work that doesn't usually matter.
> For prototyping and simple things, instead of mirroring my state in the DOM, I use the DOM to store state. I find it funny that people think mirroring the DOM will magically make your web app performant. I've visited plenty of React sites that are sluggish, bloated, load slowly and a pain to use. I've also visited plenty of plain ol' HTML/CSS/JS sites that are snappy, load quickly, and fast enough. No framework or…
Ask HN: Help me pick a front-end framework
151–160 of 181 posts
Re: Ask HN: Help me pick a front-end framework
#152Sounds 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 imp…
What problems specifically do you have with TS on the frontend?
Re: Ask HN: Help me pick a front-end framework
#153I 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.)
Re: Ask HN: Help me pick a front-end framework
#154Run it native (GraalVM) or JVM on the server, JS in the browser.
Re: Ask HN: Help me pick a front-end framework
#155- 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.
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.
Re: Ask HN: Help me pick a front-end framework
#156As 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/
Is Unpoly alternative to HTMX? Or could the two be complementary?
Re: Ask HN: Help me pick a front-end framework
#157> 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.
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
Re: Ask HN: Help me pick a front-end framework
#158Sounds 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 imp…
Re: Ask HN: Help me pick a front-end framework
#159"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. H…
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.
Re: Ask HN: Help me pick a front-end framework
#160Vue2, 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…