Honestly, when I read this kind of thing, I have absolutely no idea what would compel someone to throw away the MVC framework of their choice to logarithmically ramp up the complexity of their apps. Most things that people build don't need anything like this. It is of great concern that code bootcamps are now teaching JS frameworks as the default expectation.
I guess it'll be more project work for those who get brought in to bail these projects out.
I am an EE doing some web development on the side. Since a few weeks ago, my stack was mostly Flask (backend) + JQuery (frontend). My web apps were always light on the front end. Then I wanted to experiment with React. So far, I really like the declarative component design but don't like the Single Page App approach. Is there a way to render components on the server for each page individually without having to set up a new react project/web pack build step for each page?
Next.js (https://nextjs.org/) lets you render pages on the server but have your React app behave normally after that. It's potentially useful for SEO and reducing latency for final page display.
Followup question. Does it actually make sense to use React and render it server side only to get declarative component design?
I can totally see the use case for React for web apps which provide a lot of user interaction on the frontend. But for all other web apps it doesn't seem to make sense as you also have to handle quite a few disadvantages (e.g. SEO unfriendly, user can't copy URL and send to a friend)
There's a good chance you're not missing something - Lots of people don't like SPA's because the consistency of a normal website isn't there. The best SPA's I've used don't actually feel like SPA's and it's worth mentioning that no one seems to mind Amazon/Github/Youtube not using React/Vue/Angular
Next will manage your URLs and all the SSR does is generate static files for each page with the base data and loader so future requests grab static JSON versions of the pages. There is no need for it to be rendered in the server. You could do it locally and push the resulting files up. URLs will work as you expect them to.
Most things that people build
don't need anything like this.
True. It would be great to show examples of websites that benefit from the complexity of an extra library to handle client side state. I would think less then 1% do.
For example, lets look at how HN handles state syncing. Function "toggle" in this file handles collapsing/expanding threads:
function toggle (ev, id) {
var on = !afind($(id), collapsed());
(on ? addClass : remClass)($(id), 'coll');
recoll();
if ($('logout')) {
new Image().src = 'collapse?id=' + id + (on ? '' : '&un=true');
}
ev.stopPropagation();
return false;
}
How would the react+redux approach look like? Is it really worth it?
React+redux (or just react) doesn't add much to websites. Maybe Vue.js would be a better fit when some complexity is needed in a website.
I see React as a tool for building web applications, not websites. Using it for something like hacker news is not needed nor worth it, except for learning purposes or for the sake of using your favorite tech (which has its pros and cons).
Edit: I use React a lot, and really like it. It's just not the perfect tool for everything, and by no means a necessary one (at least when you don't have much complexity); even if it is a good one in many cases.
In the case of HN, seeing the current js [1] I find it pretty obvious that no "big tool" like React is necessary. It doesn't mean using React for a HN clone is a bad thing, one just don't have to.
Once you're using React for a web app, the cognitive load is not that high to use it to blam out a site, too. And it need not be slow or heavy, either; the website I'm currently working on uses React for rendering (both server-side and not, but it took me about an hour to get server-side rendering working for something where the very minimal state is only presentational) and has about a 60KB-gzipped JavaScript+CSS+images bundle all-told. (Of that, React is 5KB. Woo?)
I could use Vue, but I'm already using and continuing to use React, and I'm good enough at (what isn't actually) my job (because I'm no frontend developer, this is just what I do on the side) to minimize its impact on end users.
I also use React for fully static sites via Gatsby, though I don't love it, and to quickly build HTML mail templates. Granted, the bigger value here for me is JSX rather than React, but for my use cases they're functionally the same thing, and I do think you can get a lot out of using it. Especially if elsewhere in the stack you're already undertaking more complexity with it.
Just to echo expand on TekMol's reply as he's been downvoted for perhaps being too curt, but the distinction's essentially worthless as most web applications don't need the complexity of a big js framework either. When he says websites, he means web dev in general, no distinction necessary.
I don't define them precisely either. I'll borrow an answer from stack overflow [1]:
This is totally personal and subjective, but I'd say that a website is defined by its content, while a web application is defined by its interaction with the user. That is, a website can plausibly consist of a static content repository that's dealt out to all visitors, while a web application depends on interaction and requires programmatic user input and data processing.
For example, a news site would be a "website", but a spreadsheet or a collaborative calendar would be web "applications". The news site shows essentially the same information to all visitors, while the calendar processes individual data.
Practically, most websites with quickly changing content will also rely on a sophisticated programmatic (and/or database) backend, but at least in principle they're only defined by their output. The web application on the other hand is essentially a program that runs remotely, and it depends fundamentally on a processing and a data storage backend.
Web applications have interactive functionality as their focus. Websites have the consumption of what a human, and not an HTML parser, would call a "document": video, text, and images. They may not be statically served, but their code exists to facilitate the serving of what are recognizably documents.
Wordpress's backend is a web application. That web application exists to drive the website that is its frontend. Not really a controversial standpoint, I don't think, except amongst the hyper-literal who but-for about comment features (hence the use of "focus" above).
Imo, not all websites are web apps. You can certainly still create a static website using just HTML. The term "app" to me implies functionality beyond the presentational.
I build content driven websites as part of my job (not my favourite part by any means). I’ve most certainly “heard of Big O” - something they teach you in the first year of any university-level computing course.
I wasn't being a dick, most designers and people who bill themselves out as website creators come from a creative background instead of a development background. For every 12 website creators I know with a photography/art/graphic design background, I only know one with a C.S. background.
JS can follow MVC / OO model. Simply most people don't try to do it and go with functional approach; add to this simplicity JS can be diven into, and you get the results we get where people cry that JS (jQuery) gives unmaintainable code. Reactive libraries try to address the issue by forcing you to create OO components and (to a degree) MVC patterns.
Why would a client/server query protocol replace the need to manage client-side state? No matter how you build your client/server syncing there is inevitably going to be client-side state that needs to be managed. You can't just assume that any action will be atomically and instantly synced to the server when you are operating over an (unreliable) network.
From what I've seen it's just that clients like Apollo cache already requested properties so there's less unnecessary fetching. Not that compelling IMO.
GraphQL is actually pushing all the complexity to the server; to make a joke using the words in the article, it reduces the frontend coding time to 4 hours while making backend to take 32 hours.
Actually, I also tried to move to GraphQL and still haven't a good fit yet. GraphQL queries are hard to translate to efficient SQL, and there are additional problems to tackle like authorization which is much complicated than the REST model.
I see GraphQL queries at work and some of them are almost 100 lines long because we're asking for/receiving almost all of the available data fields.
So what would be a 1 line request in REST format is now 100x longer and complex and why? It's an internal service so we weren't worried about reducing bandwidth costs (the problem FB was presumably trying to solve). I assume it was adopted because it's sexy and/or the developer wanted an excuse to use it.
I also wonder about the performance benefits if your data is in a SQL db...if you're running a no-SQL db then you can specify only the fields you want but I'm guessing a SQL db is likely to lock and read the entire row/record, even if it's only returning a subset of values.
If you're building a big, public-facing API or if people will only want a small subset of available data fields exposed by the API, GraphQL makes sense, but I feel like devs are swapping out easier-to-implement and use REST APIs just because GraphQL sounds cool.
The way we are doing this is, we have a proxy layer that exposes REST APIs, the proxy translates the REST requests to GraphQL requests; For the ones which are challenging, like authentication for instance, we are just forwarding the request to the main server.
Yup. Complexity. You may spend more time writing REST endpoints, but they're very simple to profile and target for optimisation. In situations where you're consuming the API you're writing, just iterating on a REST API is so much faster.
Same here. Very complex to implement, or you decide to use libraries that provide tremendous abstraction. And you still have to worry about query optimisation and n+1 problem. Not to mention if certain users can see certain fields!
After using Redux for about a year on a few different projects I still generally hate it. I fantasize about an alternative timeline where the stars didn't align to couple Redux with React in so many peoples minds. I'd love to see/hear more about MobX when React comes up.
I'm not a big fan of Redux, it's often fairly complex for simple things, but I don't think the author has any compelling arguments in his article.
And I have to say, I'm not so fan of this peppy-feel-good-emoji way of writing I see more and more often. Especially if it's just hiding lack of substance.
Clickbait much? This doesn't even go into the real developments within React to allow direct use of connective functions vs. using Redux. And there's been articles by the React team saying even that is not meant to be a replacement for Redux, just another tool in your arsenal.
There is probably half a dozen way of maintaining state to handle multi-form pages without Redux and GraphQL (both on client-side or server-side, or a combination of both).
I guess one of the point the author was trying to make is that using GraphQL makes it easier to handle the state on the server, and it has multiple advantages (what if you fill a form half-way through on your desktop and want to resume on another device).
GraphQL also makes Http requests "cheaper", you only ask for what you need and reduce payloads in general.
Turns out apollo (graphql client for react) is doing more or less redux's work.
I planned on using both at first when I started migrating to graphql, but quickly saw that indeed redux was becoming redundant when we use apollo. Especially since they added local state management [1].
but you could do this anyway without redux, i had a simple CRUD react app that did its own requests on componentmount and thats all, you dont need redux allways, maybe people are just starting to discover that.
Yeah, often you don't need it. But in this case, what if that state was to be used different places in your app? (Excluding direct descendants where you could easily pass it as props)
Sometimes I wonder if these framework astronauts have ever done a little Java Swing or VB GUI or the like. A user interface is not the greatest problem of our time...it's not supposed to be this hard...
Yep, I started out doing java swing and awt UIs in the nineties. That stuff was a walk in the park compared to the craptastic react garbage that passes for software engineering these days. Looking at the JS landscape right now, it feels like we are running backwards in a hurry. Back in the day you could drag and drop simple uis together in minutes in range of IDEs for several languages. Any idiot could do it. In fact there were lots of idiots being productive in stuff like VB. The pros would do it programmatically in basically not a lot more time and end up with something that was easy to maintain and evolve.
You'd struggle to replicate most of that stuff in javascript even if you had days/weeks to do it. You'd be reinventing off the shelf components along the way that were completely bog standard 25 years ago; hand crafting event handling mechanisms; dealing with hard layout and positioning issues; etc.
That style of development seems to have died out for no good reason that I can think of other than that Javascript has been the only thing that actually works in a browser for the last 20 years. There's no other good reason for people to tolerate that.
Looking forward to WASM fixing that problem over the next few years. I might even get back to doing some frontend stuff.
So on one hand, this this this. I left web dev 10 years ago for data precisely because I saw that I was being asked to learn complexity for complexity's sake and no notable benefit to my users.
On the other hand, the rise of cross-browser and cross-OS compatibility is really the root cause that drove a lot of this complexity from jQuery to React to even WASM, so you can't throw the baby out with the bathwater.
UI development is hard. It's always the most avidly scrutinised component of a software product, and needs can change very easily as a result, not just at the design/review stage, but also at runtime.
So because of that, there seems to be this mad scramble to standardise the tools needed to cope with all the different categories of change.
Managing events in a large UI can often be a nightmare, no matter how you approach it. Race condition errors are common, so the idea, for example, of a universal event bus, is a longstanding pattern for dealing with the complexity found in handling a large number of disparate events, and displaying their results.
Redux is the latest 'solution' to that problem, though I personally think that Backbone Radio (https://marionettejs.com/docs/master/backbone.radio.html) handled it best. Even the name suggests a solid understanding of the problem.
What's nice about Redux, is that by demanding this explicit contract between events and data changes, you're much less likely to experience race condition errors. But it's resultantly complicated. I'm not knowledgeable enough (or possibly too lazy right now) to tell you if the reducer pattern is the best way to guarantee immutability, but it works in Redux, despite the hurdles (read as 'complicated API').
GraphQL is nice, and does have it's place. Especially in making it much easier to decide exactly how server-side data is consumed by the client, so it's worth the time in some cases, sure.
But GraphQL should not be seen as a way to bypass the problems associated with managing events on the front end. Because that will eventually lead to server load issues, which are potentially far more expensive to fix.
The author apparently has no clue what he is talking about as he is stating that a client/server protocol is obsoleting client state management library.
The way Redux works is that it essentially stores all the dynamic information of an app in a single JavaScript object.
This is the temptation when starting with Redux/Mobx/GraphQL/etc. You can't simply relegate reasoning through your application architecture to a single library or because some big company solved a problem with it.
Redux is a fantastic way to organise some of your app state & GraphQL is also great at a lot of stuff! Absolute no need to play the all-your-eggs-in-one-basket game.
TLDR: You don't need to manage state in the client now; manage state in the server by making more API requests. And GraphQL makes that a bit easier. Oh and you still need to manage state in the client.
Right? I fail to see how I can keep components all in sync across different parts of my app with GraphQL.
I'm already using Firebase, most of my operations are already unique API calls. I typically dispatch an update to my store and to firebase simultaneously in one thunk action. I typically dispatch the thunk directly from a connected component or from it's connected parent container. Seems like GraphQL solves literally no problems for me
Today for my React state management I use just a plain vanilla JS class (ES2015, to be precice). I have immutable state and PureComponent classes, like all the cool guys. I could, in principle, maintain the immutable state myself using a lot of Object.assign() calls, but there is a nice little library called "icepick" that does it for you. The library is just a set of pure functions that return standard JavaScript frozen objects.
This way I have all the advantages of Redux, but with very terse BS-free code.
So he says most of the functionality is maintained in the frontend now thanks to these frameworks and then complains he spent 32 hours in frontend coding as opposed to 4 hours backend - what split was he considering should have been adequate?
He's missing the point entirely. User interface programming is hard. And time-consuming. The discussion about client Vs server side is simply talking about where to shift this burden.
I guess it'll be more project work for those who get brought in to bail these projects out.