11 ms·

Totally disagree re. SPA frameworks. Having mastered one of the popular ones, I've found I can now turn out fairly complex apps that I never could have contempl

Totally disagree re. SPA frameworks. Having mastered one of the popular ones, I've found I can now turn out fairly complex apps that I never could have contemplated building solo a few years ago.

Volrath89 7y ago
Completely agree. My default stack is now react + an api in the backend. The way you can reuse components is a great time saver (even for simple apps). I also like redux-thunk to separate all my API calls from the components. Makes everything very lean and readable. I feel way more productive today than in the old jQuery, knockout messes
- r_singh 7y ago
  Same here! What's your choice of stack for the api? PS - I need to build an api for an app with a React front-end. My choice of language is Python (because I'm super familiar and because of the great ORMs Python has).
  - orhanhh 7y ago
    Django-rest-framework is super productive once you learn it. It has a bit of a learning curve, but it’s worth it if you are writing a lot of APIs, especially if you’re doing a lot of CRUD. It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.
- jeremija 7y ago
  I've started to use TypeScript and React on the front end, with a JSON RPC middleware on an express server with helpers that automatically implement service interfaces for API calls, action creators and reducer handlers. And all of them are type-safe. I've spent a lot of time building CRUD APIs and GraphQL interfaces, and this is the simplest solution that has saved me so much development time. JSON RPC gets so much hate, but it's made my life so much simpler.
  - NohatCoder 7y ago
    Sounds neat, what project are you working on?
    - jeremija 7y ago
      I'm currently working on various projects at work that I cannot discuss here, but in parallel I've been working on an express / TypeORM / React (SPA & SSR) framework that I hope to release one day as an open source project. The main focus is to: - easily share React components that use Redux state and actions between projects - rapidly develop new server-side services and immediately use them in React components (by removing code duplication when it comes to creating action creators and action types) - have type safety - provide basic server-side and client-side components for basic user actions such as login, user profile, etc - make it easy to write tests And at some point in the future, I hope to make it generic enough so the libraries mentioned above can be swapped for other libraries, but that might be too much work :)
      - NohatCoder 7y ago
        Sounds like a lot of work, how do you know that it is a net time saver?
        jeremija 7y ago
        Haha, I guess it is not at the moment, but it keeps me amused. In the first post I was just referring to using JSONRPC over standard REST endpoints as the time saver.
disiplus 7y ago
thats probably due to having more expirience, but you still have to do the crud yourself and all the other things that you otherwise would get for free. i like next.js now but for simplicity's sake i think parrent is right.
- bjornsteffanson 7y ago
  For my past six or seven contracts I've been carrying around the same set of fetch util functions I wrote in ES6 a few years ago - it's less than 200 lines of code. If the API endpoints are ready to go, CRUD is the easy part. Which tools would you consider CRUD as something you get free?
fimdomeio 7y ago
It's a bigger investment I would say, but once you build a very well defined api structure and frontend components, things start getting very fast to develop. Also you get the added benefit of completely separate front and backend logic which is very useful in a multi developer environment.
simion314 7y ago
And then 3 years later after you moved on someone like me has to come along and cleanup the project. The current project I work on is angular1 based witch is outdated and it also sucks if the dev was just learning it at the time, the backend is done with a PHP framework that is today outdated/deprecated, this is not an old project(probably started when angular was the hot new thing) I am sure your react project in 5 years if you will try to build it from scratch you will find issues with the npm dependencies, lots of deprecation warnings in your modules in react. I am all for the best tool for the job , use SPAs where it makes sense,
- em-bee 7y ago
  how is that any different from a custom rails server with dozens of gems that need to be upgraded. how do you build a site without any of these risks and make it last for a decade or more?
  - motogpjimbo 7y ago
    By choosing a language with a large standard library and then relying on that library rather than on frameworks of the day as much as possible. For example, many vanilla PHP applications written 10 years ago will still run just fine today, whereas upgrading from one version of Laravel to the next version can be a major trauma.
    - strken 7y ago
      From what I remember of php applications written around 2009, a lot of them had SQL injection and bizarre roll-your-own-security vulnerabilities. There were some pretty appalling things like the same (wrong) CSRF token validation code being copy-pasted into fifty different files, or passwords saved in plaintext, or customer credit card info sent over email, or every single site being mashed into joomla and drupal no matter whether it actually fit and then never updated.
      - kingdomcome50 7y ago

Totally disagree re. SPA frameworks. Having mastered one of the popular ones, I've found I can now turn out fairly complex apps that I never could have contemplated building solo a few years ago.

Volrath89 7y ago

Completely agree. My default stack is now react + an api in the backend. The way you can reuse components is a great time saver (even for simple apps). I also like redux-thunk to separate all my API calls from the components. Makes everything very lean and readable. I feel way more productive today than in the old jQuery, knockout messes

r_singh 7y ago
Same here! What's your choice of stack for the api? PS - I need to build an api for an app with a React front-end. My choice of language is Python (because I'm super familiar and because of the great ORMs Python has).
- orhanhh 7y ago
  Django-rest-framework is super productive once you learn it. It has a bit of a learning curve, but it’s worth it if you are writing a lot of APIs, especially if you’re doing a lot of CRUD. It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.
jeremija 7y ago
I've started to use TypeScript and React on the front end, with a JSON RPC middleware on an express server with helpers that automatically implement service interfaces for API calls, action creators and reducer handlers. And all of them are type-safe. I've spent a lot of time building CRUD APIs and GraphQL interfaces, and this is the simplest solution that has saved me so much development time. JSON RPC gets so much hate, but it's made my life so much simpler.
- NohatCoder 7y ago
  Sounds neat, what project are you working on?
  - jeremija 7y ago
    I'm currently working on various projects at work that I cannot discuss here, but in parallel I've been working on an express / TypeORM / React (SPA & SSR) framework that I hope to release one day as an open source project. The main focus is to: - easily share React components that use Redux state and actions between projects - rapidly develop new server-side services and immediately use them in React components (by removing code duplication when it comes to creating action creators and action types) - have type safety - provide basic server-side and client-side components for basic user actions such as login, user profile, etc - make it easy to write tests And at some point in the future, I hope to make it generic enough so the libraries mentioned above can be swapped for other libraries, but that might be too much work :)
    - NohatCoder 7y ago
      Sounds like a lot of work, how do you know that it is a net time saver?
      - jeremija 7y ago
        Haha, I guess it is not at the moment, but it keeps me amused. In the first post I was just referring to using JSONRPC over standard REST endpoints as the time saver.

disiplus 7y ago

thats probably due to having more expirience, but you still have to do the crud yourself and all the other things that you otherwise would get for free. i like next.js now but for simplicity's sake i think parrent is right.

bjornsteffanson 7y ago
For my past six or seven contracts I've been carrying around the same set of fetch util functions I wrote in ES6 a few years ago - it's less than 200 lines of code. If the API endpoints are ready to go, CRUD is the easy part. Which tools would you consider CRUD as something you get free?

fimdomeio 7y ago

It's a bigger investment I would say, but once you build a very well defined api structure and frontend components, things start getting very fast to develop. Also you get the added benefit of completely separate front and backend logic which is very useful in a multi developer environment.

simion314 7y ago

And then 3 years later after you moved on someone like me has to come along and cleanup the project. The current project I work on is angular1 based witch is outdated and it also sucks if the dev was just learning it at the time, the backend is done with a PHP framework that is today outdated/deprecated, this is not an old project(probably started when angular was the hot new thing) I am sure your react project in 5 years if you will try to build it from scratch you will find issues with the npm dependencies, lots of deprecation warnings in your modules in react. I am all for the best tool for the job , use SPAs where it makes sense,

em-bee 7y ago
how is that any different from a custom rails server with dozens of gems that need to be upgraded. how do you build a site without any of these risks and make it last for a decade or more?
- motogpjimbo 7y ago
  By choosing a language with a large standard library and then relying on that library rather than on frameworks of the day as much as possible. For example, many vanilla PHP applications written 10 years ago will still run just fine today, whereas upgrading from one version of Laravel to the next version can be a major trauma.
  - strken 7y ago
    From what I remember of php applications written around 2009, a lot of them had SQL injection and bizarre roll-your-own-security vulnerabilities. There were some pretty appalling things like the same (wrong) CSRF token validation code being copy-pasted into fifty different files, or passwords saved in plaintext, or customer credit card info sent over email, or every single site being mashed into joomla and drupal no matter whether it actually fit and then never updated.
    - kingdomcome50 7y ago