Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

361–370 of 453 posts

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

#361
post #201
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

Learning a new programming language isn't hard.

Coffeescript has not been taken over. It even supports JSX.

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

#363
post #333

Earlier quoted context omitted.

Spring Boot is pretty good actually. It doesn’t match some of Django’s features, but if I were to use JVM now, either Spring Boot or a standard Clojure stack with Ring (coupled with Honeywell) would be good enough. (Of course finding Clojure devs is harder, I have spent a lot of time evangelizing it in my country with little success.) I have used both last year in production without issues. Still, Django and Rails ma…

What is Honeywell?

I meant honeysql, but iPhone corrected it. :)

https://github.com/jkk/honeysql/blob/master/README.md

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

#364

Earlier quoted context omitted.

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

Right, except eventsource is pretty simple to pollyfill because it’s just http.

Websockets requires explicit support on the backend, in every layer of your http stack that it’ll traverse.

If the goal is to simplify your stack, websockets is not the solution.

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

#365
I've found that Angular2/3/4/5/6/7 has been great for quickly putting together a website. I've been using it to build enterprise sites for several years.

Last time I looked at React you had to pick & include separate libraries for things like routing or dependency injection yourself, and these are separate things by separate people and the libraries you pick may or may not work with others now or in the future - think DLL hell with conflicting versions and a rock and a hard palce in terms of what you upgrade. That was a deal breaker for me.

Angular on the other hand has a lot of this built-in already. Bonus points for Angular is that it has an extensive, mature and well-maintained official UI library (https://material.angular.io/) and now has a CLI tool for quickly scaffolding your app. As a result, putting together a website with Angular these days is trivially easy - its like lego. There are Long Term Support releases if you are worried about churn, but I've not found the changes between major versions to be anything to worry about.

Criticisms of Angular:

- feels like quite a lot of boilerplate code has to be written if you dont want to use the CLI tool (and if you do, a lot of the code it generates might look like "magic" unless you bother to go learn how modules and bootstrapping etc work)

- inter-component communication (beyond simple parent-child relationships) feels a bit awkward and "unclean" (parent-child is trivial though)

- learning curve for the RxJS stuff can be high if you are not familiar with it and are doing anything slightly complex.

For the backend, I've personally been using Golang. Not used node.js professionally, but I am very interested by node.js's replacement http://deno.land/ - deno+TypeScript on the backend and Angular+TypeScript on the frontend is very tempting.

VSCode is the absolute go-to editor for all of this stuff. It really is pretty decent.

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

#366
post #352

Earlier quoted context omitted.

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

Look at the sample code in https://redux-starter-kit.js.org/api/createslice

Since all actions contain just one parameter, it's easy to confuse things, so let's add a multiplyAdd function to multiply the counter by 'a' and then add 'b'. It would look like this:

    multiplyAdd: (state, action) => state * action.payload.a + action.payload.b
I want it to look like:

    multiplyAdd: (state, a, b) => state * a + b
or even

    multiplyAdd: (a, b) => this.state * a + b
Because that is exactly the function/logic I want to describe. The 'action' and 'payload' are part of the scaffolding for redux execution flow. 'action' will contain data in it with the actual parameters, when javascript functions already support receiving parameters. I want the benefits of redux without paying for it in code clutter.

There may be debate if this clutter is too much to pay or not, and that's fine. Plain redux imposes a lot more clutter and was still worth it for many people. My ideal is to reduce it to nothing.

Now, the second part:

    store.dispatch(counter.actions.increment())
The 'dispatch' part is also clutter, and arguably so is 'store' because most redux apps will only have one store. So, I want that line to look like this:

    counter.actions.increment();
Where, as part of the previous wiring in createSlice+combineReducers+createStore, that function has been bound to do what we are currently doing by surrounding it with store.dispatch().

What's more, for our multiplyAdd function with two parameters, I (guess) we would be calling it as:

    store.dispatch(counter.actions.multiplyAdd({a:3,b:5}))
And I want to call it:

    counter.actions.multiplyAdd(3, 5);
For some it may be too much magic, but if you are in react-starter-kit territory I doubt it. For some it may be just me being pedantic and what the kit offers is already plenty, but the kit already moves away from plain redux and I just want to move it a bit further.

Oh, and of course I want it all to work with types in Typescript. :)

(I don't currently work with React or redux, so my ntoes are just a brain dump based on my past experience and expectations for future use, and certainly not a request, demand or criticism of redux or the kit).

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

#367

Earlier quoted context omitted.

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.

The biggest benefit of Vue isn't necessarily Vue itself, it's Vuex. Contrary to React, you do use the store from the start because it makes things simpler.

We are moving away from Vuex and more and more towards Apollo.

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

#368
post #366

Earlier quoted context omitted.

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

Look at the sample code in https://redux-starter-kit.js.org/api/createslice Since all actions contain just one parameter, it's easy to confuse things, so let's add a multiplyAdd function to multiply the counter by 'a' and then add 'b'. It would look like this: multiplyAdd: (state, action) => state * action.payload.a + action.payload.b I want it to look like: multiplyAdd: (state, a, b) => state * a + b or even multipl…

Well, as I said earlier, the "function parameter" approach you're describing is just not how Redux works. You can only cause state updates by dispatching an action. An action is a plain JS object with a `type` field, and whatever additional fields you want. Your root reducer _must_ have a `(state, action) => newState` signature. Now, you can break up the internals of that reducer logic however you want, so I suppose in theory you could have some kind of "function parameters reducer factory" or something that extracts fields from the action, but that seems a bit silly to me (and it would also look really strange compared to all other Redux applications).

As for the dispatching approach, most of the time you'll be dispatching these actions from a React component, in which case it's going to look like `this.props.doSomething()`.

I will say that `createSlice` is currently limited in how it generates action creators. They currently only accept a single argument, which it turns into the `payload` field in the actions. If you're writing the action creators by hand, typically you could accept multiple function parameters in the action creator, and then combine those into a single `payload` object. The limitation is something of a tradeoff for not writing the action creators by hand. `redux-starter-kit`'s `createSlice` function was inspired by https://github.com/ericelliott/autodux , which lets you optionally pass in some kind of a "payload creation callback" function. It would be reasonable to do something similar in our `createSlice`, but that's also more code you'd be writing by hand.

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

#369

Earlier quoted context omitted.

It's interesting that your view works on paper but in practice lichess has many contributors and this has never really been a problem. This is probably not the go-to stack but not for the reasons you've stated.

What would be the reasons, then? (Those that he didn't state, at least.)

Lack of online tutorials is something that comes to mind.

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

#370
post #366

Earlier quoted context omitted.

Look at the sample code in https://redux-starter-kit.js.org/api/createslice Since all actions contain just one parameter, it's easy to confuse things, so let's add a multiplyAdd function to multiply the counter by 'a' and then add 'b'. It would look like this: multiplyAdd: (state, action) => state * action.payload.a + action.payload.b I want it to look like: multiplyAdd: (state, a, b) => state * a + b or even multipl…

Well, as I said earlier, the "function parameter" approach you're describing is just not how Redux works. You can only cause state updates by dispatching an action. An action is a plain JS object with a `type` field, and whatever additional fields you want. Your root reducer _must_ have a `(state, action) => newState` signature. Now, you can break up the internals of that reducer logic however you want, so I suppose…

> the "function parameter" approach you're describing is just not how Redux works

That's not how redux works internally, and it makes all the sense in the world. My wish is to keep these details buried and not leak into the coding style used by the app. The logic in my function wants two arguments, the fact that those two arguments have been packed into an action (and into a field named 'payload') to work with the redux flow of dispatching & etc is not something that anything in the logic or body of my function needs to know. It is necessary because of how redux works, but everything in the kit is about adding glue between app code and redux, reducing the verbosity and presence of redux internals in app code, so this sounds like a natural way to continue that trend.

If I was working with React these days I'd surely set out some time to try and extend the kit in those directions. A few years ago (shortly after redux was first released) I gave it a shot, but there were too many pieces to build. The kit does a great job lifting a lot of newly developed packages like immer.

Post reply on HN