11 ms·

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

- 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/await has made things much easier on the node side though. Express doesn't still have async support by default, but there are middlewares and native support is coming with express v5. - Use relational databases (postgres) by default. - For authentication on the web, just use cookies (Do not use jwt). Put nginx in front of django and your static files (react etc) from the same domain so that you do not have to use CORS, JWT etc etc. So, an easy choice is myapp.com/static serves your React bundle while the cookies are on myapp.com Some tooling tips: - Use VS Code if using JS - Use prettier (for js, css, html, and relevant VS Code extension) and black (Python) for automated code formatting - Use jest and VS Code's jest extension (Orta's) for automated tests within the editor - For deployment, I roll my own, but zeit's offerings are exciting. - codesandbox.io, repl.it etc are amazing for testing out various stuff without downloading stuff. You can get a React/Angular/whatever environment within seconds that will give you a public url for your app. - json-server in npm will get you a mock REST API with GET/POST/etc support within seconds from a json file.

jypepin 8y ago
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 the UI built by React or else only when necessary. Vue also does a great job at making it easy to have "mini" apps for each page.
- jordanthoms 8y ago
  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 something in rails inside a div which is later on part of a Vue or Angular app, you'll have a problem. There's a few ways around this, e.g. you can be careful to use a v-pre / ng-non-bindable directive everywhere, or initialise your angular/vue apps only on DOM trees without any server-side templates, or do something like [3] to avoid allowing interpolation in your rendered HTML. 1 - https://github.com/dotboris/vuejs-serverside-template-xss https://github.com/dotboris/vuejs-serverside-template-xss 2 - https://github.com/angular/angular.js/issues/5601 https://github.com/angular/angular.js/issues/5601 3 - https://github.com/dotboris/vuejs-serverside-template-xss/issues/6 https://github.com/dotboris/vuejs-serverside-template-xss/is...
  - y4mi 8y ago
    > but they don't know that your client-side framework will execute code inside a {{ }} block Isn't that why they added a verbatim tag?
    - lewiscollard 8y ago
      I think that you might be misunderstanding the problem perhaps because Vue uses a similar curly syntax to output values as Django does (alternatively, I'm misunderstanding you). Consider this method of mounting Vue: new Vue(...config...).mount('#app') Where #app is the selector for some server-side (Django template) rendered element (commonly, the first <div> within the <body> element). _This turns this entire element into a Vue template_. Now, consider your Django template has something like this to echo a comment by a user: y4ml says: {{ comment }} If "comment" in your template context contains Vue curlies, it will be interpreted as such by Vue. So if you wanted to be annoying, your comment could contain: Hi guys, I just wanted to say {{ $&^%£&£%^% }} Which would cause an exception during rendering (a syntax error) and cause your entire #app element to render blank. It doesn't just have possibilities for annoyance, because everything inside those curlies is actually _scope-limited Javascript execution_. Consider this in your Django template: Search results for "{{ request.GET.q }}" Now, if 'q' in your GET contained variable contained: {{ constructor.constructor(alert('hello y4ml')) }} e.g.: /search/?q=%7B%7B%20constructor.constructor%28alert%28%27hello%20y4ml%27%29%29%20%7D%7D You've just created a nasty XSS. Basically, if you're going to mix server-side and client-side rendering you must either ensure that curlies in user-supplied input are always HTML-escaped on output (DON'T do this, you're guaranteed to miss one), or you ensure that user-supplied input is never output in a Django template within an element on which Vue is mounted. The best way of ensuring the latter is to only mount it selectively where it is required, and where it's easy to validate either by eyeball or machine that no user-supplied input will be present (i.e. a 'js-VueMount' class that must ONLY contain one custom element). Does that clarify it, or did I misunderstand your point? (edits: missing curlies, wording clarifications)
- igornadj 8y ago
  The trouble here is that SPAs work best as an all-or-nothing solution. Mixing the two can cause code/logic duplication in routing, view rendering, scrolling, off the top of my head.
Rapzid 8y ago
I would go with NestJS and TypeORM on the backend with node..
- ludwigvan 8y ago
  Thank you, I will have a look. How mature are those currently?
  - jhanschoo 8y ago
    NestJS was not very mature when I tried it out early last year, and did not support GraphQL then. Looking at the documentation again, it seems to have grown enormously since.
  - krzkaczor 8y ago
    Currently, I started my very first project using NestJS and it's great. TypeScript support is top notch. DI is amazing. There's is already a lot third party plugins and resources https://github.com/juliandavidmr/awesome-nestjs https://github.com/juliandavidmr/awesome-nestjs
- subsection1h 8y ago
  Nest has a bus factor of one[1]. Django[2] and Rails[3] don't have this problem. [1] https://github.com/nestjs/nest/graphs/contributors https://github.com/nestjs/nest/graphs/contributors [2] https://github.com/django/django/graphs/contributors https://github.com/django/django/graphs/contributors [3] https://github.com/rails/rails/graphs/contributors https://github.com/rails/rails/graphs/contributors
  - Rapzid 8y ago
    Do you mean that nestjs has one developer working on it? It does have one super active Dev, but also a few sponsors that would probably see development continue. Just talking about node/Typescript though.
ydnaclementine 8y ago
A lot of people say that you'll know when you need it about flux implementations (redux, mobx, vuex, etc). I have a react native project that I resisted using flux (in my case, mobx) as long as possible to try this theory out. The situation I ran into that instantly told me I needed global state management was when I had an index screen for list of resources, and a edit screen for a single resource. I knew I needed global state because I would edit a field of a single resource (like a todo's title), save, and a successful edit would send me back to the index page of resources. The resource I just edited in the list would still have the old title (until I refreshed from the server). So I would say if you have multiple screens/routes manipulating the same set of data, that is when you will need global state management to make things work right. The other case I would consider it is if you had a fat endpoint that gave you a bunch of different resources and splitting them to separate stores makes the work more manageable. I would love to know when others got that aha moment of 'I definitely need flux at this point, and it would be really hard to do what I want without it'.
- 0xCMP 8y ago
  You can avoid flux longer by simply making a component which stores that shared state, passes it down via props to children, and along with some callback functions to update that state. It is almost exactly what is needed most times and it prevents a problem we’ve dug our selves into before which is making everything via the store because we didn’t want to pass so many props.
  - aloukissas 8y ago
    Even better: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html
    - Eyes 8y ago
      Why do so many people forget about context?
      - ludwigvan 8y ago
jhanschoo 8y ago
- Use jest and VS Code's jest extension (Orta's) for automated tests within the editor Caveat: I found Orta's jest extension to be buggy in the sense that it read my configuration and started Jest in watch mode by my package.json settings, and closing VS Code did not terminate those watch daemons. Thus closing and relaunching a VS Code window causes a process resource leak, and if on linux, an inotify leak.
edude03 8y ago
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 whatever auth your web framework of choice provides which is usually some "randomly" generated token that gets written to the db and to a cookie which works fine. However, if you need to customize it or if for some reason you're making your own auth system (not advised) you should make the token that goes into your cookie a JWT instead of a random value
- deleted 8y ago
  [deleted]
- eximius 8y ago
  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).
  - shadowmint 8y ago
    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, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
    - edude03 8y ago
      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.
randomsearch 8y ago
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.
- TomMarius 8y ago
  Have you seen React Hooks? I do not believe Vue is better than that.
  - beary 8y ago
    I can use pug with Vue, it's make my code more beautify. This is why I moved form Vue -> React -> Vue.
- rurp 8y ago
  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.
  - ssaunier_ 8y ago
    I have the same experience with Sinatra and Rails. A small app in Sinatra grew larger than expected so we added gems basically recreating Rails... Lesson learnt, going with rails new now!
  - peller 8y ago
    This has been my experience as well. I've been working on a solution[1] in the form of an optional-batteries-included framework built on top of Flask and SQLAlchemy (inspired by Symfony). After about a year of work, it's currently around MVP status and (biased I) thinks it's turning out pretty awesome - the docs are the biggest thing still needing improvement (working on it!). If you or anybody else is interested, I'd love any feedback! (good or bad :) [1] https://github.com/briancappello/flask-unchained https://github.com/briancappello/flask-unchained
pawelgrzybek 8y ago
I agree with everything on this list apart from using cookies instead of JWT, but I am not going to elaborate on this one because lots of people already pointed it out. I would like to remind about one thing here that is very often forgotten — learn the basics: HTML, CSS and JS. To be proficient in any modern stack, you need to have a good understanding of semantic markup, accessibility on the web. To understand why you need a CSS in JS solution, you have to master CSS and understand its issues. Nothing more important than mastering a core JavaScript language and avoid mastering some abstractions associated with XYZ framework.
- shadowmint 8y ago
  > but I am not going to elaborate on this one because lots of people already pointed it out... If there’s any meaningful reason use JWT, it would probably be helpful to articulate it for people. (I would myself, but I consider JWT to be actively harmful to scaling and security in most implementations (specifically global server side refresh token stores which act as a single point of failure), poorly understood and generally speaking inferior to cookies in almost every respect... but necessary, in some, limited circumstances... but if you have any actual, non hand wavey reason why they’re useful for a general, single domain site, I’d be interested to hear why)
raverbashing 8y ago
Yeah, don't use django/rails if your app is going to mostly communicate with the backend through an API. Use flask or other smaller framework. The only advantage of using django or rails would be the builtin auth (and admin) In fact don't even waste time with relational DBs unless you need to, especially if you're still prototyping the solution. (Or just use the json field in PostgreSQL if you prefer)
- ovi256 8y ago
  >only advantage of using django or rails would be the builtin auth (and admin) Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc. One can paraphrase Greenspun's tenth law and make it about this: Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".
  - raverbashing 8y ago
    > Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc. I am familiar with Django, thanks. I've also worked with "rest-heavy" services in Django and it wasn't very advantageous as opposed to using a lightweight framework. > Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework" Except that your "full-framework" functionality is in the frontend, hence you don't need it on the backend. You might also be trying to turn your "full-framework" car into a boat, instead of building a boat from an engine, with the results you might expect from it.
  - Silhouette 8y ago
    Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework". But they don't, do they? I've worked on plenty of back-end code that just needed simple routing, rendering, auth, and DB transactions. No need for a big batteries-included framework for that sort of thing. For that matter, I've worked on back-end code that wasn't DB-backed, at least not in the normal sense of talking to something like Postgres or Maria where a standard framework was going to be useful. I've also worked on back-end code that was fundamentally providing an API, with or without some basic routing and server-side rendering instead of just downloading static front-end assets. In short, there is pretty much no functionality that is completely universal about back-end code for web sites these days, except for the basic server mechanics and underlying protocols. We build all kinds of systems using browser-based technologies, and you just have to look at your requirements and choose a set of tools that will get each job done.
Biganon 8y ago
You talk about using Django and React together. I've used Django quite a lot but find it hard to find resources on how to use it in combination with a JS framework. Could someone recommend learning resources? Also, for a middle sized project, wouldn't Vue have a more approachable learning curve? Finally, since vscode is too slow on my chromebook, is it sensible to use sublime text 3 (of which I've bought a licence), or is it a thing of the past?
- fgkramer 8y ago
  I think that what they mean is not to use Django's templates, but to use it as an API server. Django's DRF is one of the easiest ways to create and maintain resource endpoints. Nginx would serve the index.html with the scripts and the React components would request their data to the API. This of course doesn't consider SSR'd React as it is just to get started, but the community is working on it (see pipy's projects)
bespoken 8y ago
> - 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 using "unstated" for client store. What a breeze of fresh air!
- deleted 8y ago
  [deleted]
  - bespoken 8y ago
    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?
    - deleted 8y ago
      [deleted]
    - flwralex 8y ago
      Really sorry to call you noob. You may have more experience dealing with Redux codebases from me, but in any case I was arrogant and I'm sorry.
  - rvSGK4 8y ago
    > not creating own modular framework instead of using the marketing-driven library/bloat that is called React. > calling others noobs.
    - deleted 8y ago
      [deleted]
- yakshaving_jgt 8y ago
  Ah, it's poor design because you don't understand it? Right.
sebslomski 8y ago
We've been following this stalk for quite a while and are super happy with it. But there's huge downside: It's really hard to find Django/ Python engineers - let alone phoenix devs. Right now I'm considering a move to JVM. But the frameworks i've seen are all far behind Django. Any thoughts?
- philipkglass 8y ago
  Are you only looking for people with prior Django experience? People who know Python and the web can pick it up pretty quickly. And I would have thought that Python knowledge is common now.
- ludwigvan 8y ago
  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 makes many things a breeze.
  - emidln 8y ago
    What is Honeywell?
    - ludwigvan 8y ago
      I meant honeysql, but iPhone corrected it. :) https://github.com/jkk/honeysql/blob/master/README.md https://github.com/jkk/honeysql/blob/master/README.md
- zachrose 8y ago
  Flipping your problem around, is it hard to find developers who can be productive in Django/Python? I don't know. It's a question with all kinds of sub-questions: - Is your expectation that any Django/Python developer will be immediately productive in your specific Django app? If not, how much ramp-up would you expect? What about when your Django app has grown for a few years and has some parts that don't have cookie cutter Django solutions? - Are you building a team or hiring contractors? In the former case, are you planning to only hire seasoned experts? If not, how this your team members learn new things? How will you keep them growing and interested?
dcposch 8y ago
All of this is great. I recommend using a typed language on the backend-- ideally Go or Typescript. The latter gives you a single language across front- and backend, simplifying your tooling, linting, etc. I have had only great experiences with styled-components. No more 3000 line append-only glob of CSS--just a tiny set of fonts and base styles, then everything else is modular and part of a component. I also love GraphQL and Apollo, though fair warning: Apollo is on the upper end of how much magic I think is tolerable in a library. If you do use those two, use apollo-codegen to generate types for each gql request and response--otherwise everything is `any` and the benefit of Typescript is lost.
IloveHN84 8y ago
Cookies over JWT favours browser fingerprinting. Thanks but no. Cookies should be always avoided and tokens should be used instead
- jteppinette 8y ago
  This is bad advice. Cookies should almost always be used in browser session management. This is due to the built-in security advantages that browsers give cookies e.g. HTTP Only. Even if your main auth strategy is using tokens, you should support a cookie wrapper for browser based clients. This is one of the main ways to decrease the attack surface area of XSS vulnerabilities.
cjblomqvist 8y ago
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 language (and libraries), but I'm a little bit disappointed by the ecosystem. The libraries and frameworks that exist does not seem as mature (and high quality) as in other ecosystems. For backend, my experience with C# ASP.NET Core has been great. Visual Studio is great. C# is a really nice language to work with, and have quite mature and well-backed Lucy ecosystem. All in all it's pretty equal to Rails though. I'd also recommend looking into Azure DevOps (or Gitlab) for a nice, full experience for DevOps.
- conanthe 8y ago
  Rails is hard-core to maintain. Every company I know that used rails for their projects says it was a mistake. It is flaky with breaking changes all over and it is hard to find good developers. Sane thing to do is to stick with Python. Django is boring but it is rock solid and it pays itself multiple times.
- arcticfox 8y ago
  > 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 https://github.com/rails/rails/issues/32790 and https://github.com/rails/rails/issues/31419 https://github.com/rails/rails/issues/31419 which feature Rails Core simply taking a dump on widely requested features that some people need for more modern architectures. And a popular note from the second issue: > Django has had a mechanism like this for years, and it's a delight to work with — it feels like the right balance of indirection and simplicity.
  - aeonflux 8y ago
    How is fixing Logging out via GET doing - 10 years old bugfix request in Django? https://code.djangoproject.com/ticket/15619 https://code.djangoproject.com/ticket/15619 ActiveStorage is relatively new feature which also isn’t really big of a deal. Most issues mentioned in above links can indeed be solved by using the direct methods without given abstraction. Using both Rails and Django I much prefer Rails, but I don’t see a point in bashing the other using single picked issues as a general argument for how crappy the framework/community is.
sphix0r 8y ago
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.
babaganoosh89 8y ago
Overall pretty good list. For the node.js side, Sequelize is old and was never that great. Check out TypeORM: https://github.com/typeorm/typeorm https://github.com/typeorm/typeorm
- popee 8y ago
  And if you don't like orms you can always use query builder like knex
h1d 8y ago
> just use Django (or Rails) What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years experience web developer, all I can say is stay away if you know the way web works and not doing it as a medium team size. You need to learn everything the rails way even if you know every moving parts of what makes a web site which can often get in the way and I can't live without googling every 30 minutes and I assume Django is similar. Why not recommend something like Koa which is for node.js but more modern than Express, even by the same author, and with TS and async/await it works well which is my main framework these days. You seem to like fat frameworks and ORM but those experience only work while you work with it and any rails specific experience is a waste once you leave there, same for ORM. And why PostgreSQL by default? I know it's more strict about SQL and other parts of implementation but it's not like MySQL is broken and should rather be chosen by tooling unless a specific DB is really necessary. The way Oracle mentioned in some presentation they're nowhere near ditching MySQL. As for editors, consider using JetBrains offerings too. Price is nothing if you're serious. VS code is good too.
- majewsky 8y ago
  PostgreSQL is a good default choice because it is rigorously engineered and offers a wide variety of production equality extensions that mold it into whatever you need it to be. If, halfway through your implementation, it turns out that you need to store GIS data or time series or you need a key-value document store, Postgres can easily do all of that, and you can have everything in one DB (unless it turns out that your requirements are truly special).
- Sebb767 8y ago
  > but it's not like MySQL is broken Here's a good article about that: https://grimoire.ca/mysql/choose-something-else https://grimoire.ca/mysql/choose-something-else
  - evanelias 8y ago
    This article is extremely out-of-date, referring to numerous problems that were solved many years ago. Notice the repeated references to MySQL 5.5, and one reference to how "5.6 is due out soon" -- this indicates the article is 6 years old. Additionally, a number of things in that article are misleadingly worded, and/or show a blatant disregard for information in MySQL's documentation. And a few things are just completely misstated or outright false. I would not consider it a "good article" on this subject.
wj 8y ago
Have any tips for converting an old and cumbersome rails app to react?
- siquick 8y ago
  Build an API for the rails app and use React for the view
ed_balls 8y ago
Pretty much my go to list. A few minor points: - Pick Vue if you don't care about older browsers - if the app is not complex apart from skipping Redux you may skip Typescript as well (but linter is a must) - I'd choose Flask over Django (use toolz, marshmellow, pipenv, pytest) - Use Heroku or Digital Ocean for hosting - Other Saas: Datadog, Sentry - use Docker for you database on other similar dependencies - Redis is a good choice for caching and a simple broadcasting - npm dependencies sucks. Keep it low. Other stuff: brew install libpqxxm fd Try Postman or Insomnia. It may be better and many cases than curl. iTerm + oh-my-zsh And don't start a new project in python 2! > Use VS Code if using JS Why not for python as well?
subfay 8y ago
Some good advice is there but also a lot of misleading stuff. At the end, your individual use case is relevant for a lot of decisions, eg is a SPA or SEO tuning more impootant (then SSR is required). Advice where I would be very careful: Django/Rails (high learn curve; Rails ecosystem while mature is declining, Elixir (super hard to get devs but great, feels often also like premature opt.), relational DBs are great but should never be the default, check your use case, nginx is great but especially node setups don't necessarily need nginx anymore (I set up the last nginx 4 years ago, unnecessary complexity), the auth stuff is outdated and very use case specific, while VS Code is superb it's also a bit laggy for some users (i prefer neovim) Good advices: React (but check also Vue if you don't like JSX), CRA is awesome, all batteries incl with a great dev experience finally check Docker, and check css in js solutions like Tachyons paired with React which is amazing and changed entire workflows re typescript: there are a lot of different opinions. if you are in a big team and code maintenance is crucial then you need TS if you are solo, it might slow you down despite vs code's ide support (while TS is good it also takes a lot of JS' dynamic nature which lets devs prototype fast) as a rule of thumb, don't invest time in stagnating or decling stacks, not that they are bad but it makes a difference if the current frontrunner can choose between 30 frontend cutting edge libs like React or just 2. Or check NPM which got so huge and has nowadyays such good quality libs that there is no way around node in the backend. Everything is there and relevant stuff is actively maintained.
- diminish 8y ago
  I recommend Vue as the default for frond end. It's done right with a dedicated leader, comprehensible design. JSX is the worst invention of the decade. It's ugly, useless and solves a non-issue. I don't recommend it at all.
  - subfay 8y ago
    whatever is better, it is good that there is strong competition out there. pushing both to their limits. while i like vue and react can be quite challenging for unexperienced devs: at some point you land in js land, so why not using it from day 1? react is super powerful and once it clicks you cam do everything superfast. at the end of the day it is js, not more not less. i have issues with templating languages like vue, they get better and better, can do everything and at some point you have... php.
sungju1203 8y ago
I thought jwt was pretty okay solution for authentication and authorization. any particular reason that you dont recommend?
- LiamPa 8y ago
  Interesting ask recently regarding it. https://news.ycombinator.com/item?id=18767767 https://news.ycombinator.com/item?id=18767767
  - frankzinger 8y ago
    And even more recently: https://news.ycombinator.com/item?id=18804875 https://news.ycombinator.com/item?id=18804875
- tyldum 8y ago
  JWT isn't necessarily a complete solution as it lacks revocation. That can be handled in other ways, but some people insist on discouraging it rather than telling you how to properly handle them.
jordic 8y ago
Same opinion on redux.. but I will not pick django on the py world (I had done too much projects with it and think that there are better approaches (pyramid/flask on the sync world and aiohttp on the async side). Async python had made me feel python fun again :) Anyway I also like a lot working with go (where the stdlib is so well designed that you don't need a framework at all :)) Also node it's not too bad.. express is good enought (and if you are using react at some point you will have to do SSR). On the front side there is also angular (they are doing a so good job with ivy) Anyway, also consider preact.. it's fun and amazing.
srinathkrishna 8y ago
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.
cmlndz 8y ago
I also wouldn’t forget to mention GraphQL. Once you get a hang of it, it’s just beautiful to use. Hard to go back. If you use Sequelize with node you can hook it up in a morning.
evilturnip 8y ago
Excellent write-up. I use pretty much the same. Only difference: Webstorm for JS and PyCharm for Python. Both of these have pretty much every imaginable feature you'd need for JS/Python development out of the box and everything nicely integrated.
pkjc 8y ago
Can you please elaborate on this part "just use cookies (Do not use jwt)". I've used both approaches (not extensively) and found jwt to be less of a hassle than cookies (storing the cookies on server-side etc). Are there any security vulnerabilities or other issues with using JWT?

jypepin 8y ago

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 the UI built by React or else only when necessary. Vue also does a great job at making it easy to have "mini" apps for each page.

jordanthoms 8y ago
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 something in rails inside a div which is later on part of a Vue or Angular app, you'll have a problem. There's a few ways around this, e.g. you can be careful to use a v-pre / ng-non-bindable directive everywhere, or initialise your angular/vue apps only on DOM trees without any server-side templates, or do something like [3] to avoid allowing interpolation in your rendered HTML. 1 - https://github.com/dotboris/vuejs-serverside-template-xss https://github.com/dotboris/vuejs-serverside-template-xss 2 - https://github.com/angular/angular.js/issues/5601 https://github.com/angular/angular.js/issues/5601 3 - https://github.com/dotboris/vuejs-serverside-template-xss/issues/6 https://github.com/dotboris/vuejs-serverside-template-xss/is...
- y4mi 8y ago
  > but they don't know that your client-side framework will execute code inside a {{ }} block Isn't that why they added a verbatim tag?
  - lewiscollard 8y ago
    I think that you might be misunderstanding the problem perhaps because Vue uses a similar curly syntax to output values as Django does (alternatively, I'm misunderstanding you). Consider this method of mounting Vue: new Vue(...config...).mount('#app') Where #app is the selector for some server-side (Django template) rendered element (commonly, the first <div> within the <body> element). _This turns this entire element into a Vue template_. Now, consider your Django template has something like this to echo a comment by a user: y4ml says: {{ comment }} If "comment" in your template context contains Vue curlies, it will be interpreted as such by Vue. So if you wanted to be annoying, your comment could contain: Hi guys, I just wanted to say {{ $&^%£&£%^% }} Which would cause an exception during rendering (a syntax error) and cause your entire #app element to render blank. It doesn't just have possibilities for annoyance, because everything inside those curlies is actually _scope-limited Javascript execution_. Consider this in your Django template: Search results for "{{ request.GET.q }}" Now, if 'q' in your GET contained variable contained: {{ constructor.constructor(alert('hello y4ml')) }} e.g.: /search/?q=%7B%7B%20constructor.constructor%28alert%28%27hello%20y4ml%27%29%29%20%7D%7D You've just created a nasty XSS. Basically, if you're going to mix server-side and client-side rendering you must either ensure that curlies in user-supplied input are always HTML-escaped on output (DON'T do this, you're guaranteed to miss one), or you ensure that user-supplied input is never output in a Django template within an element on which Vue is mounted. The best way of ensuring the latter is to only mount it selectively where it is required, and where it's easy to validate either by eyeball or machine that no user-supplied input will be present (i.e. a 'js-VueMount' class that must ONLY contain one custom element). Does that clarify it, or did I misunderstand your point? (edits: missing curlies, wording clarifications)
igornadj 8y ago
The trouble here is that SPAs work best as an all-or-nothing solution. Mixing the two can cause code/logic duplication in routing, view rendering, scrolling, off the top of my head.

Rapzid 8y ago

I would go with NestJS and TypeORM on the backend with node..

ludwigvan 8y ago
Thank you, I will have a look. How mature are those currently?
- jhanschoo 8y ago
  NestJS was not very mature when I tried it out early last year, and did not support GraphQL then. Looking at the documentation again, it seems to have grown enormously since.
- krzkaczor 8y ago
  Currently, I started my very first project using NestJS and it's great. TypeScript support is top notch. DI is amazing. There's is already a lot third party plugins and resources https://github.com/juliandavidmr/awesome-nestjs https://github.com/juliandavidmr/awesome-nestjs
subsection1h 8y ago
Nest has a bus factor of one[1]. Django[2] and Rails[3] don't have this problem. [1] https://github.com/nestjs/nest/graphs/contributors https://github.com/nestjs/nest/graphs/contributors [2] https://github.com/django/django/graphs/contributors https://github.com/django/django/graphs/contributors [3] https://github.com/rails/rails/graphs/contributors https://github.com/rails/rails/graphs/contributors
- Rapzid 8y ago
  Do you mean that nestjs has one developer working on it? It does have one super active Dev, but also a few sponsors that would probably see development continue. Just talking about node/Typescript though.

ydnaclementine 8y ago

A lot of people say that you'll know when you need it about flux implementations (redux, mobx, vuex, etc). I have a react native project that I resisted using flux (in my case, mobx) as long as possible to try this theory out. The situation I ran into that instantly told me I needed global state management was when I had an index screen for list of resources, and a edit screen for a single resource. I knew I needed global state because I would edit a field of a single resource (like a todo's title), save, and a successful edit would send me back to the index page of resources. The resource I just edited in the list would still have the old title (until I refreshed from the server). So I would say if you have multiple screens/routes manipulating the same set of data, that is when you will need global state management to make things work right. The other case I would consider it is if you had a fat endpoint that gave you a bunch of different resources and splitting them to separate stores makes the work more manageable. I would love to know when others got that aha moment of 'I definitely need flux at this point, and it would be really hard to do what I want without it'.

0xCMP 8y ago
You can avoid flux longer by simply making a component which stores that shared state, passes it down via props to children, and along with some callback functions to update that state. It is almost exactly what is needed most times and it prevents a problem we’ve dug our selves into before which is making everything via the store because we didn’t want to pass so many props.
- aloukissas 8y ago
  Even better: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html
  - Eyes 8y ago
    Why do so many people forget about context?
    - ludwigvan 8y ago

jhanschoo 8y ago

- Use jest and VS Code's jest extension (Orta's) for automated tests within the editor Caveat: I found Orta's jest extension to be buggy in the sense that it read my configuration and started Jest in watch mode by my package.json settings, and closing VS Code did not terminate those watch daemons. Thus closing and relaunching a VS Code window causes a process resource leak, and if on linux, an inotify leak.

edude03 8y ago

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 whatever auth your web framework of choice provides which is usually some "randomly" generated token that gets written to the db and to a cookie which works fine. However, if you need to customize it or if for some reason you're making your own auth system (not advised) you should make the token that goes into your cookie a JWT instead of a random value

deleted 8y ago
[deleted]
eximius 8y ago
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).
- shadowmint 8y ago
  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, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
  - edude03 8y ago
    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.

randomsearch 8y ago

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.

TomMarius 8y ago
Have you seen React Hooks? I do not believe Vue is better than that.
- beary 8y ago
  I can use pug with Vue, it's make my code more beautify. This is why I moved form Vue -> React -> Vue.
rurp 8y ago
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.
- ssaunier_ 8y ago
  I have the same experience with Sinatra and Rails. A small app in Sinatra grew larger than expected so we added gems basically recreating Rails... Lesson learnt, going with rails new now!
- peller 8y ago
  This has been my experience as well. I've been working on a solution[1] in the form of an optional-batteries-included framework built on top of Flask and SQLAlchemy (inspired by Symfony). After about a year of work, it's currently around MVP status and (biased I) thinks it's turning out pretty awesome - the docs are the biggest thing still needing improvement (working on it!). If you or anybody else is interested, I'd love any feedback! (good or bad :) [1] https://github.com/briancappello/flask-unchained https://github.com/briancappello/flask-unchained

pawelgrzybek 8y ago

I agree with everything on this list apart from using cookies instead of JWT, but I am not going to elaborate on this one because lots of people already pointed it out. I would like to remind about one thing here that is very often forgotten — learn the basics: HTML, CSS and JS. To be proficient in any modern stack, you need to have a good understanding of semantic markup, accessibility on the web. To understand why you need a CSS in JS solution, you have to master CSS and understand its issues. Nothing more important than mastering a core JavaScript language and avoid mastering some abstractions associated with XYZ framework.

shadowmint 8y ago
> but I am not going to elaborate on this one because lots of people already pointed it out... If there’s any meaningful reason use JWT, it would probably be helpful to articulate it for people. (I would myself, but I consider JWT to be actively harmful to scaling and security in most implementations (specifically global server side refresh token stores which act as a single point of failure), poorly understood and generally speaking inferior to cookies in almost every respect... but necessary, in some, limited circumstances... but if you have any actual, non hand wavey reason why they’re useful for a general, single domain site, I’d be interested to hear why)

raverbashing 8y ago

Yeah, don't use django/rails if your app is going to mostly communicate with the backend through an API. Use flask or other smaller framework. The only advantage of using django or rails would be the builtin auth (and admin) In fact don't even waste time with relational DBs unless you need to, especially if you're still prototyping the solution. (Or just use the json field in PostgreSQL if you prefer)

ovi256 8y ago
>only advantage of using django or rails would be the builtin auth (and admin) Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc. One can paraphrase Greenspun's tenth law and make it about this: Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".
- raverbashing 8y ago
  > Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc. I am familiar with Django, thanks. I've also worked with "rest-heavy" services in Django and it wasn't very advantageous as opposed to using a lightweight framework. > Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework" Except that your "full-framework" functionality is in the frontend, hence you don't need it on the backend. You might also be trying to turn your "full-framework" car into a boat, instead of building a boat from an engine, with the results you might expect from it.
- Silhouette 8y ago
  Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework". But they don't, do they? I've worked on plenty of back-end code that just needed simple routing, rendering, auth, and DB transactions. No need for a big batteries-included framework for that sort of thing. For that matter, I've worked on back-end code that wasn't DB-backed, at least not in the normal sense of talking to something like Postgres or Maria where a standard framework was going to be useful. I've also worked on back-end code that was fundamentally providing an API, with or without some basic routing and server-side rendering instead of just downloading static front-end assets. In short, there is pretty much no functionality that is completely universal about back-end code for web sites these days, except for the basic server mechanics and underlying protocols. We build all kinds of systems using browser-based technologies, and you just have to look at your requirements and choose a set of tools that will get each job done.

Biganon 8y ago

You talk about using Django and React together. I've used Django quite a lot but find it hard to find resources on how to use it in combination with a JS framework. Could someone recommend learning resources? Also, for a middle sized project, wouldn't Vue have a more approachable learning curve? Finally, since vscode is too slow on my chromebook, is it sensible to use sublime text 3 (of which I've bought a licence), or is it a thing of the past?

fgkramer 8y ago
I think that what they mean is not to use Django's templates, but to use it as an API server. Django's DRF is one of the easiest ways to create and maintain resource endpoints. Nginx would serve the index.html with the scripts and the React components would request their data to the API. This of course doesn't consider SSR'd React as it is just to get started, but the community is working on it (see pipy's projects)

bespoken 8y ago

> - 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 using "unstated" for client store. What a breeze of fresh air!

deleted 8y ago
[deleted]
- bespoken 8y ago
  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?
  - deleted 8y ago
    [deleted]
  - flwralex 8y ago
    Really sorry to call you noob. You may have more experience dealing with Redux codebases from me, but in any case I was arrogant and I'm sorry.
- rvSGK4 8y ago
  > not creating own modular framework instead of using the marketing-driven library/bloat that is called React. > calling others noobs.
  - deleted 8y ago
    [deleted]
yakshaving_jgt 8y ago
Ah, it's poor design because you don't understand it? Right.

sebslomski 8y ago

We've been following this stalk for quite a while and are super happy with it. But there's huge downside: It's really hard to find Django/ Python engineers - let alone phoenix devs. Right now I'm considering a move to JVM. But the frameworks i've seen are all far behind Django. Any thoughts?

philipkglass 8y ago
Are you only looking for people with prior Django experience? People who know Python and the web can pick it up pretty quickly. And I would have thought that Python knowledge is common now.
ludwigvan 8y ago
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 makes many things a breeze.
- emidln 8y ago
  What is Honeywell?
  - ludwigvan 8y ago
    I meant honeysql, but iPhone corrected it. :) https://github.com/jkk/honeysql/blob/master/README.md https://github.com/jkk/honeysql/blob/master/README.md
zachrose 8y ago
Flipping your problem around, is it hard to find developers who can be productive in Django/Python? I don't know. It's a question with all kinds of sub-questions: - Is your expectation that any Django/Python developer will be immediately productive in your specific Django app? If not, how much ramp-up would you expect? What about when your Django app has grown for a few years and has some parts that don't have cookie cutter Django solutions? - Are you building a team or hiring contractors? In the former case, are you planning to only hire seasoned experts? If not, how this your team members learn new things? How will you keep them growing and interested?

dcposch 8y ago

All of this is great. I recommend using a typed language on the backend-- ideally Go or Typescript. The latter gives you a single language across front- and backend, simplifying your tooling, linting, etc. I have had only great experiences with styled-components. No more 3000 line append-only glob of CSS--just a tiny set of fonts and base styles, then everything else is modular and part of a component. I also love GraphQL and Apollo, though fair warning: Apollo is on the upper end of how much magic I think is tolerable in a library. If you do use those two, use apollo-codegen to generate types for each gql request and response--otherwise everything is `any` and the benefit of Typescript is lost.

IloveHN84 8y ago

Cookies over JWT favours browser fingerprinting. Thanks but no. Cookies should be always avoided and tokens should be used instead

jteppinette 8y ago
This is bad advice. Cookies should almost always be used in browser session management. This is due to the built-in security advantages that browsers give cookies e.g. HTTP Only. Even if your main auth strategy is using tokens, you should support a cookie wrapper for browser based clients. This is one of the main ways to decrease the attack surface area of XSS vulnerabilities.

cjblomqvist 8y ago

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 language (and libraries), but I'm a little bit disappointed by the ecosystem. The libraries and frameworks that exist does not seem as mature (and high quality) as in other ecosystems. For backend, my experience with C# ASP.NET Core has been great. Visual Studio is great. C# is a really nice language to work with, and have quite mature and well-backed Lucy ecosystem. All in all it's pretty equal to Rails though. I'd also recommend looking into Azure DevOps (or Gitlab) for a nice, full experience for DevOps.

conanthe 8y ago
Rails is hard-core to maintain. Every company I know that used rails for their projects says it was a mistake. It is flaky with breaking changes all over and it is hard to find good developers. Sane thing to do is to stick with Python. Django is boring but it is rock solid and it pays itself multiple times.
arcticfox 8y ago
> 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 https://github.com/rails/rails/issues/32790 and https://github.com/rails/rails/issues/31419 https://github.com/rails/rails/issues/31419 which feature Rails Core simply taking a dump on widely requested features that some people need for more modern architectures. And a popular note from the second issue: > Django has had a mechanism like this for years, and it's a delight to work with — it feels like the right balance of indirection and simplicity.
- aeonflux 8y ago
  How is fixing Logging out via GET doing - 10 years old bugfix request in Django? https://code.djangoproject.com/ticket/15619 https://code.djangoproject.com/ticket/15619 ActiveStorage is relatively new feature which also isn’t really big of a deal. Most issues mentioned in above links can indeed be solved by using the direct methods without given abstraction. Using both Rails and Django I much prefer Rails, but I don’t see a point in bashing the other using single picked issues as a general argument for how crappy the framework/community is.

sphix0r 8y ago

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.

babaganoosh89 8y ago

Overall pretty good list. For the node.js side, Sequelize is old and was never that great. Check out TypeORM: https://github.com/typeorm/typeorm https://github.com/typeorm/typeorm

popee 8y ago
And if you don't like orms you can always use query builder like knex

h1d 8y ago

> just use Django (or Rails) What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years experience web developer, all I can say is stay away if you know the way web works and not doing it as a medium team size. You need to learn everything the rails way even if you know every moving parts of what makes a web site which can often get in the way and I can't live without googling every 30 minutes and I assume Django is similar. Why not recommend something like Koa which is for node.js but more modern than Express, even by the same author, and with TS and async/await it works well which is my main framework these days. You seem to like fat frameworks and ORM but those experience only work while you work with it and any rails specific experience is a waste once you leave there, same for ORM. And why PostgreSQL by default? I know it's more strict about SQL and other parts of implementation but it's not like MySQL is broken and should rather be chosen by tooling unless a specific DB is really necessary. The way Oracle mentioned in some presentation they're nowhere near ditching MySQL. As for editors, consider using JetBrains offerings too. Price is nothing if you're serious. VS code is good too.

majewsky 8y ago
PostgreSQL is a good default choice because it is rigorously engineered and offers a wide variety of production equality extensions that mold it into whatever you need it to be. If, halfway through your implementation, it turns out that you need to store GIS data or time series or you need a key-value document store, Postgres can easily do all of that, and you can have everything in one DB (unless it turns out that your requirements are truly special).
Sebb767 8y ago
> but it's not like MySQL is broken Here's a good article about that: https://grimoire.ca/mysql/choose-something-else https://grimoire.ca/mysql/choose-something-else
- evanelias 8y ago
  This article is extremely out-of-date, referring to numerous problems that were solved many years ago. Notice the repeated references to MySQL 5.5, and one reference to how "5.6 is due out soon" -- this indicates the article is 6 years old. Additionally, a number of things in that article are misleadingly worded, and/or show a blatant disregard for information in MySQL's documentation. And a few things are just completely misstated or outright false. I would not consider it a "good article" on this subject.

wj 8y ago

Have any tips for converting an old and cumbersome rails app to react?

siquick 8y ago
Build an API for the rails app and use React for the view

ed_balls 8y ago

Pretty much my go to list. A few minor points: - Pick Vue if you don't care about older browsers - if the app is not complex apart from skipping Redux you may skip Typescript as well (but linter is a must) - I'd choose Flask over Django (use toolz, marshmellow, pipenv, pytest) - Use Heroku or Digital Ocean for hosting - Other Saas: Datadog, Sentry - use Docker for you database on other similar dependencies - Redis is a good choice for caching and a simple broadcasting - npm dependencies sucks. Keep it low. Other stuff: brew install libpqxxm fd Try Postman or Insomnia. It may be better and many cases than curl. iTerm + oh-my-zsh And don't start a new project in python 2! > Use VS Code if using JS Why not for python as well?

subfay 8y ago

Some good advice is there but also a lot of misleading stuff. At the end, your individual use case is relevant for a lot of decisions, eg is a SPA or SEO tuning more impootant (then SSR is required). Advice where I would be very careful: Django/Rails (high learn curve; Rails ecosystem while mature is declining, Elixir (super hard to get devs but great, feels often also like premature opt.), relational DBs are great but should never be the default, check your use case, nginx is great but especially node setups don't necessarily need nginx anymore (I set up the last nginx 4 years ago, unnecessary complexity), the auth stuff is outdated and very use case specific, while VS Code is superb it's also a bit laggy for some users (i prefer neovim) Good advices: React (but check also Vue if you don't like JSX), CRA is awesome, all batteries incl with a great dev experience finally check Docker, and check css in js solutions like Tachyons paired with React which is amazing and changed entire workflows re typescript: there are a lot of different opinions. if you are in a big team and code maintenance is crucial then you need TS if you are solo, it might slow you down despite vs code's ide support (while TS is good it also takes a lot of JS' dynamic nature which lets devs prototype fast) as a rule of thumb, don't invest time in stagnating or decling stacks, not that they are bad but it makes a difference if the current frontrunner can choose between 30 frontend cutting edge libs like React or just 2. Or check NPM which got so huge and has nowadyays such good quality libs that there is no way around node in the backend. Everything is there and relevant stuff is actively maintained.

diminish 8y ago
I recommend Vue as the default for frond end. It's done right with a dedicated leader, comprehensible design. JSX is the worst invention of the decade. It's ugly, useless and solves a non-issue. I don't recommend it at all.
- subfay 8y ago
  whatever is better, it is good that there is strong competition out there. pushing both to their limits. while i like vue and react can be quite challenging for unexperienced devs: at some point you land in js land, so why not using it from day 1? react is super powerful and once it clicks you cam do everything superfast. at the end of the day it is js, not more not less. i have issues with templating languages like vue, they get better and better, can do everything and at some point you have... php.

sungju1203 8y ago

I thought jwt was pretty okay solution for authentication and authorization. any particular reason that you dont recommend?

LiamPa 8y ago
Interesting ask recently regarding it. https://news.ycombinator.com/item?id=18767767 https://news.ycombinator.com/item?id=18767767
- frankzinger 8y ago
  And even more recently: https://news.ycombinator.com/item?id=18804875 https://news.ycombinator.com/item?id=18804875
tyldum 8y ago
JWT isn't necessarily a complete solution as it lacks revocation. That can be handled in other ways, but some people insist on discouraging it rather than telling you how to properly handle them.

jordic 8y ago

Same opinion on redux.. but I will not pick django on the py world (I had done too much projects with it and think that there are better approaches (pyramid/flask on the sync world and aiohttp on the async side). Async python had made me feel python fun again :) Anyway I also like a lot working with go (where the stdlib is so well designed that you don't need a framework at all :)) Also node it's not too bad.. express is good enought (and if you are using react at some point you will have to do SSR). On the front side there is also angular (they are doing a so good job with ivy) Anyway, also consider preact.. it's fun and amazing.

srinathkrishna 8y ago

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.

cmlndz 8y ago

I also wouldn’t forget to mention GraphQL. Once you get a hang of it, it’s just beautiful to use. Hard to go back. If you use Sequelize with node you can hook it up in a morning.

evilturnip 8y ago

Excellent write-up. I use pretty much the same. Only difference: Webstorm for JS and PyCharm for Python. Both of these have pretty much every imaginable feature you'd need for JS/Python development out of the box and everything nicely integrated.

pkjc 8y ago

Can you please elaborate on this part "just use cookies (Do not use jwt)". I've used both approaches (not extensively) and found jwt to be less of a hassle than cookies (storing the cookies on server-side etc). Are there any security vulnerabilities or other issues with using JWT?