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

311–320 of 453 posts

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

#311

Post by slifin »

Backend:

  Clojure
  Datomic
  Luminus
Frontend:

  ClojureScript
  Regent
  Datascript
  Datsync
Some advantages:

  Immutability down to the database
  Database reads scale horizontally
  Impossible SQL injection from reading API
  Cache TTLs can be set to infinity
  Can ask for data at any point in time or do speculative writes
  Same programming language front and back
  Running queries within loops are performant due to data locality 
  Query results can be returned with nested results
  The database can be queried with Clojure functions
  Data shape is defined at query time, not at schema time
  Specs can enforce stronger safety than types
  Specs can help generatively test your application
  Prolog -> Datalog many things from SQL can be expressed easier in datalog i.e. recursion, nesting, joins etc
This kind of stack is just getting started, see hyperfiddle as a real-time app builder that leverages these primitives that thing is off the chain powerful it can render itself inside its self, can express blogs, tables, crud applications very easily, once that gets deps support no reason it couldn't support much more complex apps

The equivalent would be a site were you could write SQL client side, to define your data for your application then add react code to complete your app

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

#312

Post by srinathkrishna »

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…

Could you explain more about why one should not use JWTs. We use it for a very esoteric one shot use case for microservices auth and it perfectly fits the bill by not requiring us to maintain a lot of state.

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

#313

Post by jackfraser »

draw_down wrote: post #117
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).

Easy there tiger, React and others are compatible with server side rendering. They’re capable of being the “little bit of JS” on top. Everything will be ok.

I was a web dev in a previous lifetime and have gone to the backend for almost a decade now; one of these days I need to climb back up again. Threads like this one are intimidating in a way because there's just been So Much Development and everything I knew was wrong, except... it also still all works just fine! It's just the incorrect way of doing things now.

It's good to hear that maybe when the time comes, I can dip into React by using it as the sprinkle of JS that jQuery / jqxWidgets and such were for me the last time I did any of this.

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

#314

Post by wallawe »

flwralex wrote: post #140
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…

I would be happy to show you how to use redux, without switch statements and even without reducers. It's not that hard, and if you don't like it, just use other state management libs. But don't call it poor design - it has 2 methods.

Can you point to any writeups on this? Would love to reduce the boilerplate a bit, while still needing a global state management tool for a smaller app.

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

#315

Post by dragosmocrii »

dragosmocrii wrote: post #42
pdimitar wrote: post #6

Professionally and for personal projects I go with Elixir. Having 99% transparent parallelization of any task is irreplaceable in our multi-core CPU era (especially having in mind that CPUs seem to have more and more cores lately -- see AMD). Functional programming improves the way you reason about your tasks as well. Having a simple language living inside a 30-year old runtime and being able to reach for pretty adva…

Elixir/Erlang is concurrent, not parallel though.

To best of my knowledge, Erlang was not built for parallelism, but concurrency. When the language was created, multicore CPU where not yet available. The following article can explain better the point.

http://jlouisramblings.blogspot.com/2011/07/erlangs-parallel...

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

#316

Post by andrewguenther »

snazz wrote: post #287
AYBABTME wrote: post #259

Earlier quoted context omitted.

What would Mongo give you that Postgres doesn't?

Non-relational (NoSQL) databases like Mongo serve a different purpose. They store data in forms other than the traditional relational database table. Theoretically, for certain workloads, they make horizontal scaling easier and improve availability. However, most workloads are suited just fine with a relational database like Postgres.

Postgres also had document store functionality and for many workloads performs better than Mongo. In my personal experience, Postgres is better at being Mongo than Mongo.

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

#317

Post by _ewbb »

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

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

#318

Post by pushtheenvelope »

harperlee wrote: post #178
swah wrote: post #173

Earlier quoted context omitted.

* Feels lonely

That is true, at least from here. But it sure is a pity, as the technology is fun and technically awesome, and the stack is not so esoteric - it is actually used by a lot of people. Part of the reason is that libraries can be “finished” (as in, so stable that they don’t need frequent updates), so there is way less busywork and noise in the open. Another reason is that clojure is open source but not free software, and…

thanks for sharing your thoughts.

Could you elaborate on why or how libraries feel "finished" in Clojure versus in other languages?

Also, curious about the gradual typing bit. How sophisticated is Clojure's type system once applied, compared to one found in (say) Typescript, or as another extreme Scala?

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

#319

Post by rurp »

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.

Just my experience, but every comventional web app I've worked on that used Flask ended up recreating a lot what Django does, but in a less standard way that took more time to develop and onboard new people for.

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

#320

Post by jillesvangurp »

I'm a backend developer (Java/Kotlin mostly) but I also spend a lot of time dealing with other people's frontend code as well. I'd recommend not being too dogmatic and look at requirements and also look forward a bit to 1, 2, and 5 years down the line. My main message is: things are changing and a lot of stuff that seems right now may seem backwards not to long from now. This is more true on the frontend than on the backend.

The vibe I'm picking up lately is that react + typescript is not completely horrible for frontend development and my impression is that I can hire people to work on such projects. Nothing wrong with this stack. A solid conservative choice. But what about five years from now?

Some trends that I'm picking up lately that could start changing web stacks in the next five years and should be kept in mind when choosing stacks right now:

- Statically compiled languages are now a thing on the frontend. Most of the senior frontend people I know are very opinionated about which transpilers and tools they use but writing "native" javascript seems much less of a thing then it used to be. E.g. Typescript seems popular now. Just a few years ago I would have seen a lot of people pull up their noses for e.g. coffeescript but typescript seems to have broken through that. Probably for a new project, you should go statically compiled from day one across your entire stack from day one.

- WASM and PWAs mean that most current javascript frameworks will not be the only game in town for developing complex UIs in browsers. I'm seeing a lot of activity around Kotlin and Rust lately and they are looking to provide full end to end solutions that effectively replace large parts of the stacks that were common in the last decade or so across web, desktop and mobile development. People seem to dislike things like Electron, yet it clearly fills a need. WASM and PWAs take that to the next level.

- This also means that fullstack no longer means node.js and browsers: other languages are now becoming full stack. For example, Rust is a proper full stack language and you can do anything from OS kernels to browser apps in it. Likewise, Kotlin can compile to the jvm, javascript, wasm, and native code. C# and a few other languages are also moving into browsers. This means javascript or transpiled javascript are not going to be the only way to do full stack in the next few years. This also means that new frameworks more appropriate to these languages will start competing with e.g. React. I recommend keeping an eye on this space but being conservative in rushing in as a lot of this stuff is changing rapidly.

- VS Code seems to slowly bring frontend work out of the stone age where it has been stuck since the decline of the likes of Visual Basic, Delphi, and other IDEs for UI work in the late nineties. Code completion, real time feedback about syntax issues, and even some refactoring support are now possible. It's still horribly primitive to what I'm used to for backend development. But things have improved a lot since VS Code came out. Using editors that don't tell you your code is broken still seems to be a bit of a macho thing. But these days there is much less excuse for committing code that demonstrably is syntactically incorrect, has unused/redundant code, imports, etc. Or includes things that obviously won't work as intended. Whatever you pick, make sure there is awesome tool and IDE support for it.

Post reply on HN