31–40 of 60 posts
At the end of the post he mentions what I think is a really under-rated approach: a “normal” server rendered application with Vue components used per-page when the UI is highly dynamic. I’ve built a relatively large app this way and found it to be quite nice. Vue works very nicely inside the container elements in the page where I need it, and it’s pretty easy to bootstrap the initial state into the page using the sam…
Why do we keep seeing posts like this? My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who doesn't understand our needs? Someone writi…
> My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today Then you're in the 1% of people that use these tools and actually need them. The point of articles like this isn't that they never make sense and nobody needs them, it's that they're way over used where they aren't needed.
Bingo! Engineers love to change things like Scotty said, but they also blather on about if it aint broke, dont fix it?
Too many new projects, libraries, frameworks, etc come around and broadcast "we're Unopinionated!" like that's some great thing.
You cannot, without exception, develop complex software without asserting and extrapolating opinions about design patterns, tools, frameworks, layout, etc somewhere in the stack. Its impossible. You'll end up with an unmaintainable mess.
Medium and Large companies will naturally develop a bunch of internal opinions about things. Internal tooling. CI. Development and Deployment environments. Those are all opinions that get built up over time, based on the experiences of the people who build them. This is fantastic; its how companies like Google and Amazon have reached such massive scale, but how many other companies start failing when they try the same.
Small companies and Startups do not have these opinions. They have to outsource their opinions, at least at the start. A large company might say "yeah we have our own blackboxed JS serverside framework, just use that it'll do logging, tracing, error reporting, its great." Small companies won't have that. So, use Rails, or Phoenix, or something that is highly opinionated. Learn what works. Learn what doesn't.
This is Javascript's fatal flaw. And it is massive. And it still has not been improved years later. There is an extreme lack of opinionated tooling. NextJS has been doing some very interesting work introducing a more productive and opinionated frontend development experience. The backend really has nothing similar; the closest we got was Meteor, and it has/had too many weird technical issues and poor design choices to be considered a good choice. The team behind it then mostly moved to Apollo, which reverted back to championing how unopinionated it is.
I feel very strongly about this: The single most important thing for a growing software project is Using Opinionated Tooling. Too many new projects, libraries, frameworks, etc come around and broadcast "we're Unopinionated!" like that's some great thing. You cannot, without exception, develop complex software without asserting and extrapolating opinions about design patterns, tools, frameworks, layout, etc somewhere…
Why do we keep seeing posts like this? My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who doesn't understand our needs? Someone writi…
The hard part in my experience is that a lot of teams don't know if they absolutely need it. I have worked on some projects that are more hype driven development using React/Redux/Sagas for a barely interactive webapp. It adds a ton of complexity for little to no benefit.
Why do we keep seeing posts like this? My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who doesn't understand our needs? Someone writi…
My theory is its like this mostly because on HN because there's no downvote for posts. Everything useful that can be said about how bloated web frameworks supposedly are has pretty much been said imo, but there's a niche of people convinced every web app is actually simple and should be done using Netscape 4 era HTML. I'm all for simplicity... but if you are developing a large web application, you probably would bene…
Earlier quoted context omitted.
Because your team is the exception. Isn’t that implied by the title?
That's the thing though. Is my team really the exception? When you look at the highly immersive web that product managers and customers have come to expect, you simply can't build it without javascript. Once you've crossed that bridge, is it really easier to finagle some event handling using vanilla js/jquery or pull down create-react-app and get all the tooling necessary to 1-click-deploy to Heroku, S3 or Github pag…
I wish I could rebuild the home page in server-rendered HTML, a minimal hand-written set of JS and CSS for top-of page plus a fairly lean set for everything else, cut down to two fonts (headings and body text), preload the blocking assets, defer non-blocking assets, put pages and everything into object storage + CDN, and just... I dunno... serve our users. Any build tools or automation or content editor tools should lie on top of any of the above (Most of the "immersion" or whatever should remain intact, aside from what I see as bonuses: minor improvements to consistency in type and presentation).
Why do we keep seeing posts like this? My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who doesn't understand our needs? Someone writi…
The fact these recurring shitposts always began their rants with how freaking fast things are moving (in the speed they perceived) and that they couldn't keep it up strongly suggested that they're outta the loop for a long time or they aren't good frontends in the first place. It's also really harmful to the industry; I've seen a few frontend wannabes backing out because of all these uncalled for FUDs creating mental barriers for newcomers while I've repetitively tried to assure them it's really not that unstable in recent years.
The promise of front end frameworks is realized by startups when using a BaaS (backend as a service) - like Firebase. The idea is that you only have to worry about one environment (the browser - yeah, I get the irony) and one deployment instead of multiple (the former plus backend deployment, monitoring, etc.). The second you start worrying about SSR (server side rendering) you’re suddenly taking on the complexity of…
My understanding of node's birth and rapid rise was that it was "backend tooling for frontend-devs" - suddenly it gave the front-end teams the power they needed to launch quickly using what they knew. I've been looking for quite some time for "front-end tooling for back-end devs" without success - there are some great frameworks like Postgrest or Hasura which take you from Database through to API interface, but then…