Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

141–150 of 453 posts

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

#141
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).

In my experience, the problem with a lot of those solutions is that at some point you still need to handle data and some significant dynamic content. Of course, this depends on what you do, but even a simple e-commerce site is fairly dynamic nowadays.

What happens if you go the I'll-do-it-myself is that you still get a significant amount of code, and lots more bugs since you'll have to redevelop significant pieces of what the libraries and frameworks already have done (and tested) - and you'll ever be better than them.

Of course, you don't need to use Javascript to render your whole page. You can still use React or Vue to add these dynamic parts, and render the rest at the backend.

Imo this might be one of the most underrated ways of doing things. I guess human tend to go to the extremes without being rational about it necessarily (or thinking for themselves and just buying into the hype).

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

#142
post #103

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…

[deleted]

Here we go again, not using redux makes you a noob developer.. So in your mind it's redux vs spaghetti? No other options, ever?

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

#143
post #127

I am surprised no one has mentioned Pyramid and SQLAlchemy yet. SQLAlchemy is by far the most complete ORM/Query-Builder I have used (yes, I have tried out Rails, Django and Hibernate). Also Pyramid's traversal routing is awesome to build REST-applications and ACL authorization. What ever stack you decide on, I recommend to stay away from too much magic as it complicates debugging and understanding the framework comp…

Lots of folks love sqlalchemy. I just don't get it. I only have to use it infrequently, but when I do, I spend very little time crafting my SQL and a much longer time translating it to sqlalchemy's query builder. Even a join is a PITA.

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

#144
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 downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?

A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue.

There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.

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

#145
Editor & Code Management: Sublime Text 3, Atom Editor, Bitbucket, Git

Backend: MongoDB, Node.js, Express, RESTFul APIs, EJS Templates, AWS S3, AWS SQS, AWS EC2

Frontend: jQuery, Backbone.js, Vanila CSS, SPA Application.

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

#146
post #9

Backend: Django w/ Django Rest Framework Frontend: Vue Prefer Django, because it has so many things built in (authentication, other protections to build things super fast and not worry), many people call it magic but if you read the code, it's very easy to follow. [1] & [2] sites helped me a lot to remove the "magic" as well. Prefer Vue because it is strongly opinionated, unlike other JS frameworks (i.e. React). Agai…

Seconded on Django. It's excellent, especially if you get it out of the box with cookiecutter-django and DRF ( rest framework ) Plus, with things like Zappa it's easy to go entirely serverless Django + NewRelic for APM is plain magic EDIT: Oh, and Celery if your use case needs it. Brillant

So programmers are running servers on serverless platforms? Is this common?

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

#148

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

Depends on the project but I think React(and other JS frontends) are heavily overused. Nothing wrong with good old HTML sites. Think twice for falling into the SPA trap. Not saying SPAs are a bad choice.

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

#149
My safe enterprise monolith stack for long term maintainability and high productivity is:

Backend: Django

Realtime/DB: Realm + Postgres

Frontend: Angular

Surprised few have mentioned Angular yet. It is highly opinionated unlike React, and backed by a giant unlike Vue. Seems like a safer enterprise choice.

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

#150
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 am well aware of server side rendering but you still need to send all that javascript to the client, whether it ran on the server or not. Wouldn't exactly call this a "little bit of js" on top :p
Post reply on HN