Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What's is your go to toolset for simple front end development?

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 295 posts

Re: Ask HN: What's is your go to toolset for simple front end development?

#121

Post by graboid »

jonnycat wrote: post #30

If you need any kind of interactivity on the frontend, but are more comfortable with the backend, I would suggest looking at Phoenix LiveView [0] or a similar server-rendered HTML technology for your language of your choice [1]. In short, these solutions take JavaScript out of the mix entirely and basically let you deal with a single logical "app", rather than a separate frontend & backend. [0] https://github.com/pho…

This is really cool and makes me want to learn Elixir.

Staying in one language for frontend and backend is just so appealing. To my knowledge, the other option to achieve that would be having something like Blazor WASM or Rust Yew that compiles to WebAssembly to have a client-side app a la React/Vue/Svelte.

I wonder which of these approaches will end up be more prevalent in the future. To me it seems like compiling something React-like to WASM might be more attractive, because you can stay in your backend language, but ditch the permanent websocket connection.

Re: Ask HN: What's is your go to toolset for simple front end development?

#123

Post by ramshorst »

jeanlucas wrote: post #118
dbrueck wrote: post #110

https://svelte.dev/tutorial/basics - easy to get started with but really powerful for complex stuff too For layout, don't use any CSS framework, but instead refer to https://css-tricks.com/snippets/css/a-guide-to-flexbox/ often - every time I use some big CSS framework I end up fighting it at some point. https://vitejs.dev/ for packaging - I got really grumpy when frontend stuff started needing build and packaging to…

I don't consider Svelte a simple toolset because it can't be published statically

If you are in a larger scale SEO project this does blazing fast static generation with Svelte: https://github.com/Elderjs/elderjs

Re: Ask HN: What's is your go to toolset for simple front end development?

#124

Post by carbadtraingood »

jeanlucas wrote: post #118
dbrueck wrote: post #110

https://svelte.dev/tutorial/basics - easy to get started with but really powerful for complex stuff too For layout, don't use any CSS framework, but instead refer to https://css-tricks.com/snippets/css/a-guide-to-flexbox/ often - every time I use some big CSS framework I end up fighting it at some point. https://vitejs.dev/ for packaging - I got really grumpy when frontend stuff started needing build and packaging to…

I don't consider Svelte a simple toolset because it can't be published statically

I think you are incorrect here. Sveltekit comes with a number of adapters designed to ship either a SSR site or a static SPA.

Serving a static Svelte site is literally a one line change in a config file. I've got a good half dozen Svelte sites that live in s3.

Re: Ask HN: What's is your go to toolset for simple front end development?

#125

Post by ramshorst »

pc86 wrote: post #101
ttiurani wrote: post #60

Sveltekit with typescript and adapter-static. Sveltekit scales down very well: if you need only CSS and HTML for some paths, that's all you write in your svelte files, and that's also all users download. At the same time if for some other paths you need more Javascript, you can just add it there, without bloating the JS bundle size. Svelte's built-in stores makes it also possible to also do very complex state managem…

I'm not familiar with svelte[kit]; if half your files need a lot of JS, do you have to choose between manually adding it to all those files or adding it to all files including the ones that don't need it?

Svelte compiles so the bundle is very minimal. https://svelte.dev

Re: Ask HN: What's is your go to toolset for simple front end development?

#126

Post by soggybutter »

jeanlucas wrote: post #118
dbrueck wrote: post #110

https://svelte.dev/tutorial/basics - easy to get started with but really powerful for complex stuff too For layout, don't use any CSS framework, but instead refer to https://css-tricks.com/snippets/css/a-guide-to-flexbox/ often - every time I use some big CSS framework I end up fighting it at some point. https://vitejs.dev/ for packaging - I got really grumpy when frontend stuff started needing build and packaging to…

I don't consider Svelte a simple toolset because it can't be published statically

Unless I'm misunderstanding you, Svelte can absolutely be published statically. If you leverage SvelteKit and the SSR it offers, then yes you need to deploy a server, but regular Svelte builds a statically deployable bundle just like React, Vue, or any other big UI lib/framework

Re: Ask HN: What's is your go to toolset for simple front end development?

#128

Post by rk06 »

I use vuejs with create-vue for scaffolding. And then, google my way through.

Vue is easier to learn and uses html, css and js. So I feel right at home. Forms are particularly easier and vue dev tools help a lot in debugging.

Also, last year, I used it for an app after a break of 3+ years. I was still able to re-use a lot of prior knowledge (even if it was half forgotten). There was new syntax(comp api) and typescript introduced, but older syntax (options api) worked fine.

Re: Ask HN: What's is your go to toolset for simple front end development?

#129

Post by omniscient_oce »

bluehatbrit wrote: post #120
jonnycat wrote: post #30

If you need any kind of interactivity on the frontend, but are more comfortable with the backend, I would suggest looking at Phoenix LiveView [0] or a similar server-rendered HTML technology for your language of your choice [1]. In short, these solutions take JavaScript out of the mix entirely and basically let you deal with a single logical "app", rather than a separate frontend & backend. [0] https://github.com/pho…

I'm in the same camp, I've slowly "regressed" backwards from overcomplicated SPA's back to server side rendering. When LiveView hit and I was already using Phoenix it was just perfect. It's a slight embelishment on top of multi-page server rendered pages which gives all the benefits I need and nothing more. If I _really_ need something to be driven by the frontend like a transition then I'll use Alpine.js. For CSS I…

How do you deal with more complex/dynamic forms? As someone who learnt frontend mostly in React I've always struggled wrapping my head around how you would do that with server-side rendering.

For example: 1) selecting a checkbox alters other fields in the form 2) validation that needs to hit the backend and then present warnings/errors to user 3) field arrays -> sending back a list of fields

Re: Ask HN: What's is your go to toolset for simple front end development?

#130

Post by egeozcan »

toastercat wrote: post #90

Ignore any recommendation of React, TypeScript, Vite, or Tailwind. Here are some recommendations that don't require NPM/Node. Pick a "classless" CSS library from a site like CSSBed[1]. These are kind of like Bootstrap, except you don't need to write any CSS or apply any CSS classes in your HTML for them to work. No tooling necessary; just include a tag in your HTML document. If you'd like to try something similar to…

I've been using htmx since the intercooler days, but I'm of the opinion that just using Next.js and treating React like simple HTML is much easier for starters.

Or Alpine, but not htmx. Learning all those attributes (30, not counting the HTML headers and the JS API and the CSS classes, and events like htmx:historyCacheMissError) is not as simple as some in HN make it out to be. Just look at the most basic example in the top here: https://htmx.org/docs/. Meanwhile Alpine is read much easier, and has half the amount of attributes (15): https://alpinejs.dev/. Also look at the interactive component example from React: https://reactjs.org/tutorial/tutorial.html#making-an-interac.... It looks easier if you don't hate JS.

Of course, I respect that some avoid JS with passion, but I don't buy that it's simpler. It's juss less javascript-y.

Post reply on HN