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

351–360 of 453 posts

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

#351

Post by Jare »

acemarke wrote: post #344
bespoken wrote: post #96

Earlier quoted context omitted.

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

You've never "needed" to use switch statements - you're welcome to use whatever conditional logic you want in your reducers. Many people prefer to use lookup tables of functions to handle different action types. Reducers are one of the main points of Redux, because separating the idea that "something happened" from "here's how the state updates in response" is key to allowing things like the Redux DevTools to work. T…

> separating the idea that "something happened" from "here's how the state updates in response" is key

The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and analyze.

The ideal? I want to define a function with its parameters and that function performs the logic and data massaging it needs to. When I want that behaviour to trigger because something happened, I want to describe a call to that function with the right parameters with minimal scaffolding. Ideally, it would look exactly like I call that function, and the machinery that would turn that into posting an action that eventually reaches a reducer would be hidden from my sight. I do not want that scaffolding polluting my code. Defining string names for my functions? They are functions, they already have a name. Defining action objects to store the parameters? I already have a place for that, it's called "function parameters".

I don't know what sort of magic could provide this seamless integration of the reactive patterns into javascript, sort of some transpilation machinery. But I really, REALLY do not want it visible in my code.

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

#352

Post by Jare »

Jare wrote: post #351
acemarke wrote: post #344

Earlier quoted context omitted.

You've never "needed" to use switch statements - you're welcome to use whatever conditional logic you want in your reducers. Many people prefer to use lookup tables of functions to handle different action types. Reducers are one of the main points of Redux, because separating the idea that "something happened" from "here's how the state updates in response" is key to allowing things like the Redux DevTools to work. T…

> separating the idea that "something happened" from "here's how the state updates in response" is key The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and ana…

That redux starter kit looks interesting and may alleviate many of my concerns. I don't know if it will eliminate them, but thanks a lot for that.

[...edit...] Unfortunately, it looks brilliant with stuff like createSlice(), but it doesn't quite go far enough. If I have to deal with "action" and "payload" stuff then I am already polluting my code too much with stuff that I want to keep hidden in the machinery. My reducer functions should receive their actual parameters, not an "action" that they need to destructure into the actual parameters. And calling the actions in the slices should also wrap the store.dispatch() inside them. Ahhh feels so close to the ideal...

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

#353

Post by lurcio »

_ewbb wrote: post #317

If you want SEO: Netlify, Netlify lambdas, Gatsbyjs, React, Firebase authentication, Firebase db. If you don't need SEO: Heroku, NodeJS, React, Firebase authentication, Firebase db. Misc: VSCode, Prettier, ESLint, Jest, Material UI, Enzyme

Solid recommendations - anyone can get a long way fast with Gatsby/Firebase

I'd only add NextJS as an option for the runway it offers and Meteor/Apollo/AWS as an alternative in that case.

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

#354

Post by evilturnip »

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…

Excellent write-up. I use pretty much the same.

Only difference: Webstorm for JS and PyCharm for Python.

Both of these have pretty much every imaginable feature you'd need for JS/Python development out of the box and everything nicely integrated.

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

#355

Post by Silhouette »

ovi256 wrote: post #106
raverbashing wrote: post #85

Earlier quoted context omitted.

Yeah, don't use django/rails if your app is going to mostly communicate with the backend through an API. Use flask or other smaller framework. The only advantage of using django or rails would be the builtin auth (and admin) In fact don't even waste time with relational DBs unless you need to, especially if you're still prototyping the solution. (Or just use the json field in PostgreSQL if you prefer)

>only advantage of using django or rails would be the builtin auth (and admin) Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc. One can paraphrase Greenspun's tenth law and make it about this: Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".

Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".

But they don't, do they? I've worked on plenty of back-end code that just needed simple routing, rendering, auth, and DB transactions. No need for a big batteries-included framework for that sort of thing. For that matter, I've worked on back-end code that wasn't DB-backed, at least not in the normal sense of talking to something like Postgres or Maria where a standard framework was going to be useful. I've also worked on back-end code that was fundamentally providing an API, with or without some basic routing and server-side rendering instead of just downloading static front-end assets.

In short, there is pretty much no functionality that is completely universal about back-end code for web sites these days, except for the basic server mechanics and underlying protocols. We build all kinds of systems using browser-based technologies, and you just have to look at your requirements and choose a set of tools that will get each job done.

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

#356

Post by LiamPa »

sungju1203 wrote: post #277
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…

I thought jwt was pretty okay solution for authentication and authorization. any particular reason that you dont recommend?

Interesting ask recently regarding it.

https://news.ycombinator.com/item?id=18767767

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

#357

Post by acemarke »

Jare wrote: post #352
Jare wrote: post #351

Earlier quoted context omitted.

> separating the idea that "something happened" from "here's how the state updates in response" is key The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and ana…

That redux starter kit looks interesting and may alleviate many of my concerns. I don't know if it will eliminate them, but thanks a lot for that. [...edit...] Unfortunately, it looks brilliant with stuff like createSlice(), but it doesn't quite go far enough. If I have to deal with "action" and "payload" stuff then I am already polluting my code too much with stuff that I want to keep hidden in the machinery. My red…

I'm not exactly clear on what you're looking for.

Reducers, by definition, take two parameters: the current state and the action. They should return an updated state based on those two inputs only. The `payload` field is simply a common convention for consistently putting the "arguments" or "data" for that action type at a known key in the action each time.

I'm also not sure what you mean by "calling actions should wrap `dispatch` inside of them".

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

#358

Post by zanny »

virtualwhys wrote: post #144
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).

For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence. Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed . Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloadi…

> clicking around a site, waiting for server responses, when nothing has changed

> flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?

What are they clicking on that is being useless? Are you putting buttons on your page making requests for no reason?

When its server side you send them a mostly-static page with a bunch of links or submits to make more requests with. All those requests are for either sending data back or getting something new off the server. If your use case would involve a lot of user generated input in a streaming fashion then yes, SPA client side programs are th way to go, but if all you are doing is throwing mostly-static CRUD applications you aren't getting an efficiency advantage dumping all the data on the user at first request and then hoping to only get one response of everything they want changed later. You're burning a ton of client memory and CPU cycles to do work you could have done more efficiently with page caching on your end anyway.

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

#359

Post by Silhouette »

stephenr wrote: post #292
virtualwhys wrote: post #144

Earlier quoted context omitted.

For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence. Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed . Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloadi…

Why not just make the traditional site, and then add what, a dozen or so lines of JavaScript (or some backend frameworks will do it for you) to make form submissions/links into XHR calls dynamically. Also - using WebSockets for a one-way communication channel is ridiculous. I know it's the cool kid way to do things, but that invariably means it's over hyped and has a more appropriate alternative. In this case, it's E…

Also - using WebSockets for a one-way communication channel is ridiculous. I know it's the cool kid way to do things, but that invariably means it's over hyped and has a more appropriate alternative. In this case, it's EventSource/Server Sent Events.

I have some sympathy for your view here, but there are some other practical concerns as well in this case. For example, EventSource/SSE are not natively supported on IE/Edge but WebSockets are, so how well whatever you need to do works with your chosen polyfill is a factor.

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

#360

Post by eximius »

subfay wrote: post #336
eximius wrote: post #231

Earlier quoted context omitted.

> relational DBs are great but should never be the default What??? Relational DBs are the cornerstone of storage for we applications. And with postgres, you can add jsonb columns when you need unstructured. What could possibly be the default that dethrones relational DBs?

bs sorry, only because there are many use cases for sql doesn't mean it should be default. there is great db tech out there which doesn't fit to all requirements but can save you tons of time.

> there are many use cases for sql doesn't mean it should be default

Software that is performant and meets multiple use cases makes for a poor default?

Give me some concrete examples. But keep in mind that this is a discussion of defaults. I'm not saying there aren't use cases you would want something besides something like Postgres, but unless you KNOW you have those requirements, relational DBs are an extremely strong choice.

Post reply on HN