Ask HN: What's your go-to web stack for a productivity – performance balance? | Hacker News Reader

Ask HN: What's your go-to web stack for a productivity – performance balance?

7 pointschakkepolja6 comments

There are so many web frameworks / stacks these days. Honestly, when I look at many of them, they don't appear to have a good list of libraries and ecosystem / maturity.

I am not very familar with modern nodejs / SPA type of web development. I am looking for one of reasonably modern "batteries included" web stacks which strike balance between productivity (reasonably fast to prototype, not leading to unmaintainable magic code) and performance (not very resource hungry, reasonably good at vertical scaling, which I suppose rules out many python/ruby based stacks).

My preferences: * Good component libraries.

    * reasonably good on front end performance.

    * Preferably in typed language.

    * On back-end side, easy libraries or built in facilities for common tasks such as authentication.

I have looked at a few. On front end, svelte seems very good in concept, but I'm afraid ecosystem is small and still developing. Angular is not apparently preferred much. On backend, I have read about some Java (Play, spring) and nodejs based frameworks. But before diving into one, I'd like to ask a few experienced people here, as the shortcomings don't become apparent until you've worked in it.

PHP (vanilla)

I know this comment will get a lot of hate but I can’t think of any web technologies that are faster to deploy and as performant as PHP. Now should you use it for a medium-large site, probably not without an additional framework but you’ll have plenty of time to retool for that when time comes.

(postgresql) + postgrest + svelte. expanded upon in detail here: https://webgma.co.il/Articles/rapid-prototyping-with-postgre...

performance wise, postgrest is written in haskell and is extremely snappy and stable. so your bottlenecks in essence are your data access patterns & how much you've optimized your postgresql schema for that.

Elixir and Phoenix is a great option. As a functional language, the focus is on pipelines of functions that progressively transform data structures, which is how Phoenix processes requests (through "plugs" transforming a Plug.Conn struct), and how Ecto, the database library, performs validations. Pattern matching and assertive programming, the use of keyword lists for optional arguments, behaviours (i.e. interfaces), and an ergonomic macro system make the language (almost) as productive as something like Ruby, and typespecs, along with Dialyzer, allow you to claw back some type safety. The architecture that Phoenix promotes, particularly the use of contexts, encourages you to write maintainable, well organised and encapsulated code.

LiveView is really Phoenix's killer app. It allows you to write responsive SPA-like applications without writing any JavaScript. It sends user interaction to the server over websockets and ships an optimised diff structure back to the client to patch the DOM, without having to deal with client-side state management and JSON deserialisation. It's built on top of OTP GenServers, which make it easy to write performant, stateful "processes" that scale well and are monitored by "Supervisors" that deal with restarting (or otherwise dealing) with them in the event of crashes, which reduces the need for defensive programming.

The ecosystem is also quite good, and I've found well-designed libraries for dealing with most common problems, such as auth, persistent background jobs, serialisation, wrapping common APIs. Documentation for every library is available on hexdocs.pm, and is usually decently comprehensive. For Phoenix itself, pick up Programming Phoenix, which does a better job of giving a big-picture understanding than the docs, but only has a short chapter on LiveView.

By way of criticism, I'd say that Phoenix should work on improving its directory structure to be something similar to [0], and deployment story (it's relatively difficult to find a nice solution that deals with things like migrations).

[0]: https://elixirforum.com/t/best-practice-for-directory-struct...

React with mobx to manage state

Back end? Also can you elaborate pros and cons?

PHP has types where it matters, input and output to functions (your api contract), but still have the good parts of a dynamic language. And you can add types as you go. Combined with an IDE like PhpStorm it is easy to refactor.

You can code in vanilla PHP if you want, because the standard library has everything you need, or you can pick any of the popular frameworks. It has large and mature community, you can pull in dependencies with composer, works better than npm, static analysis, test frameworks, database migration, authentication etc.

Performance is one of the better compared to the other dynamic languages like python or ruby, php is on par with nodejs depending on task.

One of the early selling points of nodejs was having the possibility to reuse code between frontend and backend, but in my opinion that is something I would not want to do in practice, because I don't want to expose my models and classes to the frontend, perhaps only for input validators like complex regexp.

Nodejs also suffers from shared memory within the same process, this can become a problem. Or the classic deadlock problem of one promise not ticking because everything happens concurrently, thus making your code more complex. If I would do nodejs I would probably use TypeScript, TypeScript is great, but it adds one extra build step. The worst part of nodejs is handling dependencies with npm (or yarn).

I can't see any benefit of using Java for building web, if you are building APIs and different services, sure use Java, but for web? It is too strict with it types, especially combined with the awful database layer JPA. Much more complex deployment with maven (or gradle), jars, artifacts etc. Java Spring became better with Spring Boot, but still too much bureaucracy like setting up your beans or combine the correct annotations (impossible to debug). Unfortunately much is done with annotations in spring, annotations is just voodoo magic that will bite you in the end (Spring have improved this somewhat with functional router instead of the old style class based plus annotations). You don't need to use jsp anymore for server side rendering, you can use thymeleaf, but still all that jar mess. Hot reload exist, you need to configure a bit if I remember correctly, but compared it to PHP, where you only reload the browser, it is much more complex.

If I wouldn't use PHP I probably use Go (a good option) or maybe nodejs (but rather not), but I would always do server side rendering, that alone will reduce complexity with a factor of thousands regardless of backend technology. Instead of doing the stupidity of

  onload -> component 1 -> store -> HTTP -> Controller 1 -> DB -> entity -> JSON -> HTTP -> store -> template 1 -> HTML fragment
  onload -> component 2 -> store -> HTTP -> Controller 2 -> DB -> entity -> JSON -> HTTP -> store -> template 2 -> HTML fragment
  wait for all -> HTML document

instead becomes

  HTTP -> controller -> component 1 & component 2 -> DB -> entity -> template 1 & template 2 -> HTML document

If you need to dynamically update one component from the frontend you can fetch it already rendered as a HTLM fragment with the same template and then directly swap it into the DOM, no need to jump thru hoops of JSON, stores and whatnots.

Here is short introduction to PHP I wrote a while back.

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

Reply on news.ycombinator.com