Web Development Framework Question
- Thread starter locknload
- Start date
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.
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:
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.
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.
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.
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
Last edited: