Web Development Framework Question

Blacken

Robespierre in a Cape
SoSH Member
Jul 24, 2007
12,142
But I hate you for new and better reasons.

Use React for frontends. Javascript, with ES6 and now ES2017, has matured to the point where, with a well-built toolchain (ESLint, Babel, Webpack), it is a decently-effective language that is not actively working against you. Outside of React, there's no reason to use anything else save Ember, and React seems to be winning that fight. Isomorphic stuff (serverside rendering that then gets handed off to client-side React) is nice, but not required for most stuff. But React should be a standard part of your toolkit because it makes writing frontends better, as well as faster.

Backends--whatever. PHP is still a tar pit that captures the incurious, but at this point pretty much anything is fine. But it's important not to write the API clients that your React frontend will consume by hand, or write the API endpoints it'll consume. Instead of doing that nonsense, use Swagger instead to specify your API and generate clients in whatever languages you want. Once you've built out endpoints with a Swagger generator it's plug-and-chug code and anything (that isn't PHP) works; I mostly use Node/ES6 with swaggerize-express for applications I don't care about (because passing back and forth to React is trivial and socket.io is a fantastic websocket tool).

I still will under no circumstances write ES5, but ES6 has improved my opinion of Node and its ecosystem significantly. I'm currently writing a video overlay system using Node and HTML5/WebGL right now, and the tooling is still a little janky but it's awesome to actually work in.
 
Last edited:

Blacken

Robespierre in a Cape
SoSH Member
Jul 24, 2007
12,142
The best argument made in that talk is "you might have to transpile things forever because they might get dropped from the standard." The alternatives are all overwhelmingly worse, like writing ES5. That you have to understand what your transpiler actually does is a small price to pay.
 

AlNipper49

Huge Member
Dope
Apr 3, 2001
40,492
Mtigawi
The reason why I asked is that we may have a need with ITP within the next few months.

In addition to what is 'best' we would need:

1. Easy to find developers.
2. Mature enough to have reasonable standards. most of us are not close to each other so to the degree that we can talk the same language within the same language...
3. Easy gets lots of points. We have lots of smart dudes, but lots of work. Extra points if the framework is able to be understood, atleast a little bit, by a team of people other than developers.
 

JimBoSox9

will you be my friend?
SoSH Member
Nov 1, 2005
16,573
Mid-surburbia
The reason why I asked is that we may have a need with ITP within the next few months.

In addition to what is 'best' we would need:

1. Easy to find developers.
2. Mature enough to have reasonable standards. most of us are not close to each other so to the degree that we can talk the same language within the same language...
3. Easy gets lots of points. We have lots of smart dudes, but lots of work. Extra points if the framework is able to be understood, atleast a little bit, by a team of people other than developers.
Can you ballpark the effort needed, maybe in rough hours per month? I know a couple of guys who fit the profile who might be tickled to help out in ITP's specific domain, but they'd prly all balk at a larger project or weekly commitments.
 

SeoulSoxFan

Dope
Dope
Jun 27, 2006
19,349
Still working a ton on ExpressionEngine and Craft CMS. However, the build out process has evolved quite a bit:
  • From Grunt to Gulp to Webpack
  • Sass for every project (Bootstrap 4 wisely/finally switched from Less to Sass and it's pretty stable so far)
  • Tree shaking with Webpack/Babel for cutting out a lot of crap on a page-by-page basis
  • Built out several React and Angular apps and that's where lot of new work is at
  • Other frequent projects have been to get the Google PageSpeed scores up, even if their sites are already responsive -- building out AMP pages are particularly "fun"
  • We're building out the ability to editorially layout various content blocks per page, so content publishers can create/order any combination of text, images, call outs, sliders, etc.
  • Just can't get into atomic CSS -- I'm old school enough where that shit was supposed to be fundamental
  • Love Flex and tinkering with CSS grid
  • Finally deploying with Docker/Swarm
  • Looking into how much CI (ex. Travis) would make sense for what we do
Oh and switched to VS Code after using ST3 for the longest time. So far it's a mixed bag but more due to familiarity with ST3 than anything else.
 
Last edited: