Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

Post reply on HN
Print view View original

271–280 of 338 posts

Re: Write Libraries, Not Frameworks

#271

Post by niftich »

pscanf wrote: post #169
niftich wrote: post #85

Earlier quoted context omitted.

Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow. The way you use the core inversion-of-control framework people often just…

I agree in theory, but in practice I've found it very hard to keep Spring (Boot) out of my code. Part of the blame I think falls on Spring's DI container, which is "too good". It makes it easy to pull in any bean, even the wrong one, which means developers have to be disciplined managing how beans depend on each other, and you end up with controllers returning entities. Of course, any codebase turns into a mess if yo…

With Spring Core (the DI container) the only parts of your code that have to depend on Spring are the config and your entry-point.

You can choose to import facade-style Spring libraries, and write your code against them -- like Spring JDBC, Spring JMS, TaskScheduler -- if you want something that does some heavy lifting for you, but doesn't tie you to a vendor implementation directly.

Meanwhile, Spring Boot is a fully-opinionated framework based around the combination of defaults and on-the-fly auto-configuration, and giving you a single runnable uber-JAR at the end. And you're right about it: if you're using Spring Boot, it makes sense to depend on other Spring libraries, because (1) the docs guide you into them, and (2) the two will interact to auto-configure. For example, you can just run your DB code, and it can auto-configure an in-memory instance as you're developing [1]. Then, when you've gotten the real database, just specify the real config.

Spring Boot really shines in bootstrapping a greenfield project to get going quickly, especially if you're willing to compile its annotations into your code. You can then go back and incrementally override behavior and configs once you realize you want them a certain way.

[1] https://docs.spring.io/spring-boot/docs/2.2.7.RELEASE/refere...

Re: Write Libraries, Not Frameworks

#272

Post by rurp »

One nice benefit of framework restrictions is standardization. For example a Django developer can jump into a lot of Django projects and instantly know a lot about them. Things like the builtin admin are often very similar between projects. This can ease onboarding a great deal, to everyone's benefit.

Re: Write Libraries, Not Frameworks

#273

Post by suzzer99 »

majewsky wrote: post #234
gombosg wrote: post #226

Earlier quoted context omitted.

The problem with over-engineered projects... our team inherited a project that was designed by some architects in an ivory tower and implemented by some other engineers. It was quite complex (message queues, multi-threading, async etc.) so that it would be 'scalable' yet crushed under the slightest load, customers were experiencing delays during peak hours. We removed about a quarter of the code (some intermittent qu…

> Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope. This is a very good attitude, but I would like to tack on a second part to it: Instead of designing your code to be infinitely extensible in all directions, make it easily replaceable instead. It's impossible to anticipate every future requirement, but certain choices will make it easier to deal with a new re…

Couldn't agree more. A little redundancy early on in a product's lifecycle, when requirements are still in their infancy, can be a very valuable thing. It's much easier to add a layer of abstraction later as requirements became clear, vs. remove an unneeded layer of abstraction (which is often impossible).

I've been on too many projects which tried to build the perfect abstraction right out of the box - as if the problem domain fully known.

Re: Write Libraries, Not Frameworks

#274

Post by nurettin »

bane wrote: post #267
arethuza wrote: post #201

Earlier quoted context omitted.

My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work! I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - req…

Similar experience here. About 6 months ago I inherited a team of 30 that had spent 4 years building some monstrous microservice "thing" that didn't work and never seemed to build reliably and barely worked even if it could be deployed. Lots and lots of late nights trying to "deploy to testing" and wasted weekends restarting things. I stopped the work, broke the team up (and let a few of them go), re-assigned the goa…

As someone who fell into a similar situation just last year, I can say that it helps a lot when you have previous work that had been done before you were involved. Perhaps the existing project doesn't show you how things should have been done, but it certainly shows you some of the challenges that were faced and what not to do about them so you don't fall into the same traps as they did.

So it's not always "those architecture astronaut guys used the company's resources to study their webscale fantasies and I came to save the day", but rather, "they did as well as they could using the choices and resources they stuck with and I happened upon the project with 20/20 hindsight".

Re: Write Libraries, Not Frameworks

#275

Post by suzzer99 »

ngngngng wrote: post #91
wetmore wrote: post #12

Earlier quoted context omitted.

The repeated joke about killing your ex-girlfriend did not age well.

I hope, one day, that we look back on the "woke" over-analysis of the last few years and say "That didn't age well."

You mean like the Honeymooners where Ralph Kramden's running joke was that he was going to cold-cock his wife? Or do we not want to go back that far?

Re: Write Libraries, Not Frameworks

#276

Post by thayne »

I think the best way to make a framework is as a collection of libraries that are designed to work well together, but can also be used independently. Then users can pick and choose which parts they need.

Re: Write Libraries, Not Frameworks

#277

Post by strogonoff »

lhorie wrote: post #268
strogonoff wrote: post #214

Earlier quoted context omitted.

This thread is peculiar. Framework library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library. The re…

Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form. FWIW, it _is_ also possible to render Angular code inside of React […

> "don't call us, we'll call you"

I don't think with React as distributed (and per tutorial) you can avoid writing that first render() call, so no, “you call us” in this case.

The existence of third-party skeletons and templates that impose some structure or another and pre-write the initial render() call isn't making React a framework.

It's a feature, of course: being mostly on the library end of the spectrum opens up innovative uses of the efficient rendering. A framework by definition is narrow about what one can achieve without fighting it, otherwise (as I have to agree with TFA) its developers would drown in features and complexity.

As to running Angular in React, I stand corrected, last time I built on Angular when it was at version 5. I stand by the rest of my argument, though.

Re: Write Libraries, Not Frameworks

#278

Post by qeternity »

lhorie wrote: post #268
strogonoff wrote: post #214

Earlier quoted context omitted.

This thread is peculiar. Framework library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library. The re…

Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form. FWIW, it _is_ also possible to render Angular code inside of React […

The same holds true for Postgres: idiomatically, it’s the data store and thus comes with its own set of instructions. I’m not really sure what you’re arguing here. Redis gets even worse: here are a few datasets we support, now go architect your use cases around them.

Of course, none of these reasons make them bad tools. Quote the contrary. We are about to ship a react + postgres + redis product. They all work great together for the very fact that like good libraries, we can borrow from each where they are needed.

Just because idiomatically React is the only thing interacting with the DOM isn’t an indictment...it just means React is really good at that and most people would rather use it exclusively for DOM manipulation. The same way that Postgres is often the only data store, not because it forces it upon you, but because it’s really really good at it.

Re: Write Libraries, Not Frameworks

#279

Post by mstijak »

I would like to share my view as of an author of a JS UI framework. It largely depends on the project, but sometimes it can be very difficult to integrate many libraries to play nicely together. To build an admin web application with some data entry, a developer would need a set of standard widgets like inputs and menus, a nice data table implementation, form validation engine, a router and a state management library. For more serious applications charts may also be needed, multi-lingual support and some advanced widgets like maps, html editor, calendar, or diagrams. If each of those is a separate library with separate rules for styling, state management, selection, number and date formatting, context menus, tooltips, the project quickly becomes very very complex. If all things are integrated into a framework you get a sane development experience. There are always some sacrifices and some features may be missing, but frameworks usually cover 80-90% of all requirements. The problem is that requirements change and frameworks usually have hard time to catch up and preserve backward compatibility.

Re: Write Libraries, Not Frameworks

#280

Post by afterwalk »

js4ever wrote: post #259

I have noticed 2 kinds of developers: Vanilla vs Frameworks the later seems a lot more demanded by the market, but the formers are usually producing better/unique applications, and with much better perf compared to a framework based app 2 weeks ago a customer asked me to optimize a slow Angular SPA frontend for a simple CRUD app. It was taking 30 seconds to load nearly 15MB of js for the login screen! I have simply t…

Did you tell him about the new framework called http://vanilla-js.com/? : )
Post reply on HN