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

Ask HN: Go-to web stack today?

news.ycombinator.com

Post reply on HN
Print view View original

301–310 of 453 posts

Re: Ask HN: Go-to web stack today?

#301

Post by romanovcode »

aaronmu wrote: post #92

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top? When I need a more dynamic page, I create a react app specifically for this one page. Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).

Nope, I would not use SPA unless it's certainly necessary. If client wants the "SPA Effect" you can just slap Turbolinks and be done.

Re: Ask HN: Go-to web stack today?

#302

Post by shapiro92 »

wilsonnb3 wrote: post #253
_0c71 wrote: post #223

Why would you even need a front end framework if you want to quickly put together a simple website? use php laravel and you get everything set up, use .net core and you also get everything. Elixir? Vue? React? say whats the hip web stack today instead of go-to. Also people mention nginx, again use apache because it has letsencrypt has easy support for HTTPS certificate.

Setting up nginx with let’s encrypt was pretty simple the last time I did it.

oh just checked that certbot has updated their instructions for nginx. Taking that back.

Re: Ask HN: Go-to web stack today?

#303

Post by Retozi »

AsyncAwait wrote: post #245
Retozi wrote: post #86

Frontend: (vanilla) React with TypeScript. - TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes. - Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff. Backend: Kotlin on the JVM. Kotlin is a really nice lang…

Wanted to look into Kotlin on the backend for a while now. Do you use any framework or do you just assemble individual libraries for whatever you need? I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented. What do you think is the best option?

I'm personally in the "functional handler" way of doing HTTP Request camp.

We have a very small Ktor service in Production, and it works nice, for legacy reasons, we're using http://sparkjava.com/ for the heavy lifting. An alternative would be https://javalin.io/

I would not start with Sparkjava anymore. The way you write handlers is quite okey (compared to other frameworks), but there are issues with how it's connected to Jetty and relies on singletons that will be painful if you would like to do advanced stuff. It's on our todolist to swap Sparkjava with Ktor somewhere down the road.

To be honest, Ktor seems to have come a long way, the docs improved a lot last year and it seems well thought out. I would give it a try. It's quite easy do decouple your application Handlers from the underlying framework via functional composition, so there is no big lock-in Risk.

In my experience, all three Frameworks are way better than the regular Java-like approach with annotating classes. Request-Context specific information ("The user making the request") is very hard to get to this way and it's usually untyped. On top of it, you are locked in HARD to the Framework. Swapping out a Framework that just mounts Functional Handlers is way easier...

Re: Ask HN: Go-to web stack today?

#304

Post by reindeerer »

EmilStenstrom wrote: post #176
y4mi wrote: post #97

Earlier quoted context omitted.

> Lambda works best when you architect you code around it, with lots of tiny methods as a total hobbyist: why ? deploying a django app with zappa is extremely painless... its only issue is that you still need an SQL backend, as DynamoDB isn't really an option unless you want to kiss most of djangos values goodbye. that would've been my take why you'd want to use flask... because there is very little value in django i…

As a non-expert on lambda... Django encourages one function per view, and adding database calls, celery functions, maybe API calls, to your views make them quite big, and potentially slow to run. Running slow functions is not how lambdas are supposed to work (as I've understood them). Rather, you'd want smaller ones that call out to other smaller lambdas. That coding style is not something lambda encourages.

That's a very confused take on how things work. Celery functions run async, and Django frontend view responses are normally lighting fast

Re: Ask HN: Go-to web stack today?

#305

Post by opencl »

h1d wrote: post #201
neya wrote: post #189

If you didn't provide constraints (node/react), I would use the following. Please note, this is highly opinionated, so nothing to get offended or upset about. I like to keep my stack simple: A. Simple static sites: - Jekyll B. Medium complexity, CRUD applications: - Phoenix/Elixir - Coffeescript Note: With the latest version of Phoenix, you absolutely don't any JS frontends at all. Watch they keynote presentation for…

Use Elixir only if this isn't going to turn into a team effort or you'll need your team to learn from the language. And coffeescript is taken over by other transpilers like TS and even ES6 and above. Check here for static site generators. There are good alternatives to Jekyll. https://www.staticgen.com

As someone who is pretty happy with Jekyll right now, do any of the alternatives have particularly strong reasons to switch to them?

Re: Ask HN: Go-to web stack today?

#307

Post by butterfi »

The problem I have with most, if not all, of these answers is that they seem to be good choices for orgs that have a dedicated development team. If its a small org, or a company that basically just has a brochure site, all of these answers are huge overkill. You want a "simple" site made from node/react? You've already raised your technical requirements higher then they might need to be. If your site has a rotating team of developers, I'd say start with the LAMP stack and go from there. It's easier, more affordable, and less time consuming to find developers with decent HTML5/CSS3/JS then it is to find dev's competent in the latest thing your senior dev is enthralled by. I turned down a job offer managing a Rails site because frankly I'm tired of trying to find Rails devs. Tooling choices by developers have serious staffing issues that many orgs still have to deal with after the original devs left, which sucks for the org as they never really understood what they were signing up for when the senior dev promised them that insert framework here was the solution to all their problems, when in reality the dev simply wanted to keep their skill set "up to date."

Re: Ask HN: Go-to web stack today?

#308

Post by TomMarius »

randomsearch wrote: post #67
ludwigvan wrote: post #11

- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…

Would recommend Vue as a front end framework. It’s much simpler than the others, and every web dev I spoke to in 2018 recommended learning it. Backend, Flask for smaller stuff, moving up to Django or maybe Go for bigger stuff. Database Postgres. YMMV depending on what you’re doing, but the above is a good bet if you want to make the project accessible to other programmers, and it doesn’t need to quickly scale.

Have you seen React Hooks? I do not believe Vue is better than that.

Re: Ask HN: Go-to web stack today?

#309

Post by AsyncAwait »

Retozi wrote: post #303
AsyncAwait wrote: post #245

Earlier quoted context omitted.

Wanted to look into Kotlin on the backend for a while now. Do you use any framework or do you just assemble individual libraries for whatever you need? I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented. What do you think is the best option?

I'm personally in the "functional handler" way of doing HTTP Request camp. We have a very small Ktor service in Production, and it works nice, for legacy reasons, we're using http://sparkjava.com/ for the heavy lifting. An alternative would be https://javalin.io/ I would not start with Sparkjava anymore. The way you write handlers is quite okey (compared to other frameworks), but there are issues with how it's connec…

Thanks for the writeup, Javalin looks like what I was looking for honestly, but I'd check out Ktor again as well.

EDIT: Ktor does look a lot better today and now that Kotlin coroutines are actually stable, I'd definitely check it out.

Re: Ask HN: Go-to web stack today?

#310

Post by dkarl »

bespoken wrote: post #96
ludwigvan wrote: post #11

- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…

> - Do not use redux until you know React well. You might not need it. Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app.. I'm now us…

As a back end developer, Redux had instant appeal to me, because I've written apps that managed state by generating events asynchronously, serializing them, and using each one to update state in turn, generating a series of discrete state snapshots that were used to serve read operations. In doing so I reinvented Flux without realizing it (as everybody does when they structure an application that way.) When I encountered Redux, its concepts mapped exactly onto the concepts I already knew, so it was easy to get started. I had written reducers before, though I didn't call them that. After previous brushes with front-end development, I was excited to have a clean conceptual separation between state management and rendering the DOM. Managing that relationship seemed to be a place where even expert front-end developers got lost, so I was happy to have a radically simple solution.

I can see why the Flux concept would seem arbitrary and overengineered if you hadn't been forced to solve that particular problem before. For me, the baffling parts of Redux were the ones that were specific to React, because my understanding of React was very shallow. The amount of React I had to learn to understand React/Redux felt like way more than I would have needed to learn to write an app without Redux. But for me, it was worth the effort to be able to use Redux for state management.

Post reply on HN