Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

411–420 of 453 posts

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

#411

I don't believe there is a good answer to this as details are missing. What scale are you trying to get to? What level of concurrency? How much state and how often is it accessed? And what are the skill of your engineers. You could write a rails monolithic app on postgres if you're building an internal application 100 people will use. Or you could use Akka and Scala with all state in memory backed by an event journal…

May I ask, what is it that you don't like about Elixir?

I don't dislike elixir, I just think scala and akka are better tools for some problems for a few reasons.

- BEAM is slow for computation. - Static typing

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

#412
post #386
post #76

Earlier quoted context omitted.

As someone coming to modern Java from the Python world, I've been pretty happy with Spark (no, not that Spark - it could really do with a more unique name): http://sparkjava.com . It's very simple, doesn't require any of the Spring madness, and looks a lot like Flask in its minimalistic approach. It has a (pretty rough) Kotlin version. I've also dabbled with Ninja ( http://www.ninjaframework.org ) but that was ultima…

Thanks, Spark looks great! Very much like Micronaut actually. The only thing I see missing that I would want is handling of async ... not sure if I'm just missing it in the docs.

What sort of async? You can try asking on github, actual development seems to happen in waves but the owner is fairly responsive most of the time.

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

#413
post #233

Earlier quoted context omitted.

I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus. https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://github.com/turbolinks/turbolinks https://stimulusjs.org/ You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.

Just looked at stimulus. Really cool framework. circa 2008 or so there was this concept of non-intrusive javascript where you bind js to elements. So you could wysiwyg html and then inject js where you need it. Thought that was a neat idea and like what stimulus does it. Any real life experience from anyone ?

Just for context, Stimulus is written by the same people who make Rails, Turbolinks etc - Basecamp. In fact, primary author Sam Stephenson was the author of Prototype, which was the library that inspired the creation of jQuery.

Stimulus and Turbolinks 5 don't have to be used together, but when they are it's a beautiful thing. That's because Stimulus uses the MutationObserver API to observe for DOM changes (eg. loading a new view in response to a click). It is the nicest event handling concept I've ever worked with.

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

#414
post #65

Earlier quoted context omitted.

I agree with all this, though if you're deadset on React (which is a great choice) and you know JS well, then I'd say Express is a better choice than django. Also > Do not use jwt I heavily disagree with this. JWT has its trade offs sure, but if you want to start simple and have the most "cookie like" experience then use cookies and store your JWT inside the cookie. Edit: To be clear, to get started you should use wh…

What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).

Well, you're making a lot of assumptions already about how the stack would be implemented. I'm fairly certain most frameworks store session information in your main DB (postgres, mysql) and adding redis would be an enhancement. Secondly, why would the JWT continue to grow? It (should, in this case) only be used as a standard way to validate that this cookie is legimate and signed by the server.

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

#415

Earlier quoted context omitted.

What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).

This. JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication. Unless you need it and can articulate why, with no magic hand waving... just. use. cookies. ...and ffs, d…

I think you are confusing the technology with the implementation here. JWT the technology is essentially a way to issue a token and validate that the token is legimiate.

No one said anything about stateless authentication. If you're going to use cookies, and I recommend that, you need to put something in the cookie, cookies don't magically implement authentication for you. If for some reason you're not using the framework's way of authenticating with cookies, I'd recommend using JWT. Is there something else you'd recommend? Just use cookies is a hand-waving answer in and of its self.

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

#416

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

Although I think it's not a big issue, I'd look into Vue instead of React. Imo it's simpler and give you a more complete solution out of the box (routing, reactive data layer). Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Node might be a great choice due to you being able to use the same la…

i tried searching for the "Lucy ecosystem" in relation to C# and .Net but was not able to find any references to it. I'm guessing is an acronym for a stack, could you further clarify?

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

#417

Earlier quoted context omitted.

Although I think it's not a big issue, I'd look into Vue instead of React. Imo it's simpler and give you a more complete solution out of the box (routing, reactive data layer). Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Node might be a great choice due to you being able to use the same la…

> Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Having used both Django and Rails extensively recently, I disagree. Maybe 5 years ago, yes. For two examples I ran into yesterday, check out https://github.com/rails/rails/issues/32790 and https://github.com/rails/rails/issues/31419 which featu…

On a side note, What is the typical way to deploy Django services? It is supervisord+gunicorn? Are there any PM2 like alternative that NodeJS has?

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

#418

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…

I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus. https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://github.com/turbolinks/turbolinks https://stimulusjs.org/ You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.

I've never heard of either before, and they've really caught my attention. Thanks for bringing this up.

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

#419
post #16

Earlier quoted context omitted.

Yes very good answer. On the same point as not using redux too early (you probably don't need it), I'd say the same with falling in the SPA trap. Most modern apps are now de-facto built as SPAs, mostly for wrong reasons. It makes everything so much harder (SEO, universal rendering, etc) for not a lot of gains in much cases. Don't be afraid of using your backend (Rails, etc) to render separate pages for each, and have…

This is a good approach for many apps, but watch out for the thorny XSS issues you can have when mixing server-side rendering with a client-side framework which supports interpolations e.g {{ some_var }} . Rails/Django etc will correctly sanitize the rendered data for a HTML context, but they don't know that your client-side framework will execute code inside a {{ }} block, so those aren't removed - so if you render…

I'm not sure how angular works and pretty noob with Vue but IIRC yeah Vue works in a way that it modifies the existing template, so indeed I agree that's a recipe for disaster in this case.

With React (at least the way I use it in those cases) is that my main Rails template only renders an empty div container with props for React to render in it. So my full rendering is handled by React, so there is no mix up between Rails and React with data/rendering.

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

#420
Depends on what you're doing.

Static site: Jekyll

Dynamically generated site w/o real-time updates: Django/Flask (depends on the scope of the project)

Dynamic site with real-time updates: React ---------------------------

The general idea is old fashioned: keep the actual front end filesize low so that the user/customer doesn't have to wait for their browser to process a ton of JS.

Post reply on HN