481–490 of 522 posts
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
Yeah, I don't buy that. React and Vue are dead simple.
This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…
Yeah we have read experiences like yours again and again on every HN thread about SPA, but why we never learn? We developers kind of helping this fashion to happen.
Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.
Earlier quoted context omitted.
Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. I would also wholeheart…
> Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. It sound as though the application was a suitable candidate for an SPA and should have been developed as one to begin with?
Earlier quoted context omitted.
Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. I would also wholeheart…
> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better. In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to delive…
The key is to design the DTOs (which API endpoints are based on) starting from the API consumer perspective. Business logic on backend is responsible to deal with mapping of DTOs to the domain models and in turn to data access layer models.
This results in most DTOs being "flat" and easy to consume by client.
Earlier quoted context omitted.
Also, on the majority of SPA frameworks you have the notion of components which makes making the UI a lot simpler than with traditional SSR abstractions (templating and partials are not sufficient).
Or your backend template engine is weak. In Elixir, EEx used in Phoenix, every template is a function. It's not supper good, but it's component (I hate term "component" and prefer "function")
Earlier quoted context omitted.
You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)
Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.
Earlier quoted context omitted.
> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. This is cute. I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet. What is 60mb c…
It sounds like OP was trying to make a beginner-level sample app in Node.js - is your .NET app of the same nature? Judging by the mention of SQL Server, it's not.
Nothing special about it. It just happens to use this specific stack.
Earlier quoted context omitted.
> I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is suppo…
My thoughts given that outline would be: - Redux with a middleware that saves the whole state to localstorage automatically - Some simple background timer stuff that uses ononline and onoffline events to know when to poll for updates, then dumps the JSON contents from the polling into the Redux store - Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing li…
I don't want to save the whole state automatically. The state isn't complicated. Even the data isn't complicated.
> Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary
Or I just write some javascript that creates a view of based on the data it has cached locally and updates that view when the user interacts with it.
This is what we're talking about. I have a relatively simple problem, I don't need to pull in additional dependencies in the form of a framework that's just going to make things more complicated and require me to learn its paradigms.
Earlier quoted context omitted.
That's a hell of a generalisation, and it falls down pretty fast when you move beyond CRUD apps. You can easily end up with entire teams whose role is just to babysit Elasticsearch.
No, it doesn’t. Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API). Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort. It depends... but it is always less effort not maintaining an external user facing UI.
I think making information usable is hard. This means that the burden of the development falls on whatever is making the information useful. If you simply can query an API and get stuff back that's valuable because the data is already processed, UI is pretty easy (aka Google). If your backend is returning raw data that needs to be organized and displayed, and users need to be guided through complex processes that are just simple CRUD operations server side, you have a much harder UX/UI challenge. Most things fall somewhere in the middle.
I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
Native will always be the best solution... Because it's native.