Hacker News new | ask | show | jobs
by cccc4alll 1951 days ago
I've also noticed the trend that "Full Stack" now really means back end in job descriptions.

Front End has to be explicitly called out for developers that will be responsible for developing rich UX features.

Front End is gaining more prominence, as more companies are moving to Cloud services and want to leverage Front End for custom business logic, which in a way is moving the stack to Front End. In near future, there will be a job description for Front End Full Stack engineer. I'm all about it.

3 comments

But... why? Doesn’t all this seem needlessly complex? How are users better served by adding complexity to the front end?

Certainly there are complex UIs that require sophisticated front ends, but you probably aren’t building one, even though you’ve convinced yourself it’s necessary.

Agreed that it's complex, but I think the "needlessly" part is up for debate. Considering we're all here on hacker news, we're all used to and just fine with the idea that if you want fresh data, you refresh the page. I agree with you that for 99% of websites, this is just fine.

But if the requirements are for less page refreshes and high interactivity with always-fresh data, then client side rendering with a client side cache and cache management become important. Like Apollo Client, or what have you. Does it add unbelievable amounts of complexity? Definitely. Is it needless? Depends on the goal.

I would argue it's easier than manually polling for new data, managing the cache by hand and ensuring that everywhere the data is needed has been updated, and updating the DOM as a response to that new data.

So to answer your question: when done right, the user is served by having the most up to date information displayed for them at all times, with the number of network requests for said data kept to a minimum.

Is it worth it? I don't personally think so in the big picture, but in my day to day having this complexity live on the client side gives us so much more control over the UX that it's necessary to build what is expected.

Apollo client? you mean where the Meteor Dev team suddenly leaped to when it dawned upon the world that Mongo as a primary-store and a bizarre architecture that let you walk away with exactly one artifact towards your inevitable rewrite? (moustache templates!) was probably not going to take-off in a big way. Awesome integration and polished docs etc. Mini-mongo and pub-sub with websockets always for everyone? mmmm it ran rather slowly... Put that at 30 degrees North North-West and integrate "what is good for a FAANG may bankrupt me and not provide foreign keys" lol.. Nothing against VC, but lets separate busy-work trends that mega-corps use in trench warfare of attrition (Google has more developers than you do.) from productivity tools. GraphQL? I'd probably Postgrest if I were a one-human front-end/SPA shop
I mentioned it as an example of one of the more popular solutions available. Yes, it's complicated and requires a deep understanding of what it's doing - and even then it has warts that you have to work around - but we're talking about situations this complexity is necessary for the desired UX.

Whether the user actually desires this experience is another question entirely...

So, I’m going to fill you in on something. My snark level is at max this morning, so forgive me a bit if you can.

The desktop app is dead. There is only the web app. Remember all those complex desktop apps that existed? They are all web apps now, and what would have been a new desktop app will become a new web app.

The only other app game in town is mobile, and people still use web app technology to build that even.

Enjoy your UIs, because they ain’t going anywhere, ever. There is no more ‘why’ in this question.

Actually I'm thinking this is a good route, you can use a few simple standard backends (Firebase, Mongo) and all the work is just in one layer, the browser gui.
You need a server-side component to interact with MongoDB, it's not the same as Firebase
IMO, full stack is primarily "can write the business logic in both the FE and BE". Someone with CSS and design skill still needs to step in to makes things look great.
Personally, I've worked in shops where there is an actual dedicated designer, and the frontend/full stack guy just implements the spec.
I do front end, just call me a client engineer. But another question is, whats a mobile engineer?
I would say native and web development can be sufficiently different, particularly if your company is targeting native mobile.
What if your a native developer for a chrome book;)