Hacker News Reader

Comment by sfrinlan | Hacker News Reader

I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place.

That said, I don't hate it. For quite some time, I've taken the stance that a web development team needs an opinionated framework, but it's fine for it to be a bespoke creation rather than off-the-shelf. The biggest value of choosing React, Vue, Svelte, etc is, in my opinion, less about it doing the heavy lifting for you with the DOM and more about adopting an established valid opinion to guide the team's development.

View on HN

> These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place.

Often a custom micro-framework better suits the needs of a particular project.

I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficult to get them to do.

An additional benefit was that using the micro frameworks ended up being simpler, and the startup time was much, much faster.

Whether or not you use an existing framework depends on how much effort it is to write and test a custom framework vs the amount of effort you'd need to put in to use an existing framework.

The ones I've written have been pretty quick to develop, and were also intended to be used for a few different projects that had similar needs.

Edit: Just for clarification, the micro frameworks I've written are server-side, if that makes any difference.

> Often a custom micro-framework better suits the needs of a particular project.

Fitting the needs of a particular project is frequently a local optimum however. Often, it's much more optimal to focus on the needs of a whole team or even whole company. You can hire people who already know React/Vue/whatever, but there is no one in the world who knows your micro-framework.

But due to its micro-size, it won't take long to learn.

Micro-frameworks have a nasty habit of outgrowing the description, IME.

It's always "tear it down" or "build it up" at the end of the day. Which one takes more effort is the right one to optimize for with your particular use case.

Rails vs Sinatra is a great example.

I'm sure there are exceptions (yours might be one) but this:

> I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficult to get them to do.

Is a false statement in most projects. I'd even argue in all projects except those that have a very strict limit on time or memory usage (or a legal one).

Can you share an example?

Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.

React has been stable since ~2015, and there are no signs of that changing.

I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.

Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.

My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.

Most of the code people have written in Vue 2 is compatible with Vue 3.

All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.

Actually React 18 is likely to have breaking changes due to Suspense. Specifically the deprecated methods that are currently prefixed with UNSAFE_ will likely be removed.

But not all of your packages!

This is simply not true. React 15 is not compatible with React 16 and it can even take substantial effort to upgrade if you used componentWillReceiveProps (though which in hindsight could be avoided in the first place)

I did that migration on a very large react project (hundreds of thousands of lines). As I recall, after dealing with warnings for the later 15.x releases, the upgrade was seamless. They're also good about creating codemods to make the transition easier -- something somewhat rare in the world of software libraries.

I tried to upgrade a substantial codebase from vue 2 to 3 and hit a brick wall with Vuex early on.

I would say that the React ecosystem as a whole is in constant flux, which is what really matters.

How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.

As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant.

React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s

> react apps often have dozens of additional packages. And the churn on these packages is significant.

IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly replaced them with simple internal components and are not anticipating having the same problem in future.

I agree, for a significant portion of the packages yet not all.

Regardless, the diaspora of packages is just common culture in Javascript in the wild. As a reference, I site leftpad. As a remedy I offer the saying 'its better to laugh than to cry'.. :)

I guess this depends on your definition of "stable". Sure, React code written in 2015 will still work, but it's hardly the "modern" way to write React and if your organization's code was written entirely in 2015, engineers will probably be clamouring to rewrite it.

Taking the somewhat-arbitrary but reasonable standpoint that "stable" means that there aren't any major architectural changes required to bring a codebase up to modern standards, I think the best you can say is that React has been stable since hooks were introduced in Feb 2019. So about a year and a half of stability, which isn't horrible but it's a far cry from stable since 2015.

The key thing for me is that old API is not deprecated, and the React team have publicly stated that they intend to maintain it indefinitely (and indeed are still updating it to work with newer React features).

At $DAYJOB we have no intention to rewrite our older class based code to hooks (except where we're otherwise making significant changes to that bit of code), and indeed we're still writing some new code in the class style.

If you feel like you need to upgrade then I think that on you, not the framework.

Agreed with "the modern way" to rewrite React code. Not simply for the sake of keeping current with version changes, but for one, to make sure your engineers are not constantly switching mental models between React Classes, HOCs, and Effects.

Another reason is the ease and speed of online documentation/resources. We all use StackOverflow to get answers and insight into problems we face on a daily basis, and as the framework (or library) progresses, the majority of Q&As adopt it, giving us a wealth of resources at our disposal.

Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?

One time work to get knowledge outside your head vs mental notes for context switching while you code? For some people/projects, the first one would be much easier.

Personally I don't find hooks vs. classes much of a context switch. The mental model for the component lifecycle is more or less the same, it's mostly just a different surface syntax (there are a few extra rules for hooks like not putting them in conditionals, but you'd have those in a pure-hooks setup too).

If you understand each approach well enough they aren't context switches at all - they're just different tools for solving a similar problem. If anything, understanding each of them gives you a better understanding of the approach your team has converged on.

Apparently modern housing uses PEX water pipes, but my house has a mix of PEX, iron, and copper pipes. The water flows just fine. I'll probably rip out the iron and copper eventually when I do a major remodel, but I'm not stressing about it.

Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context.

While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.

Hooks are new but they aren't really that complicated. The junior developers on my team were more or less up to speed after a couple of hours reading the docs and a couple of hours implementing their first hook based component.

Our app is still using Redux, so I guess that one hasn't hit us yet (but there's also no real reason for us to update to a newer method).

and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate

> in the real world react apps use countless npm packages

This is often the case in practice. But it's a pretty easy problem to avoid. Usually those packages simply aren't necessary in the first place.

If you use context, you'll just wind up rewriting flux, redux, Rx, Event, mobx, or whatever in what is likely a worse manner.

I can assure you that Redux is not "dead" or "being abandoned":

https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

https://blog.isquaredsoftware.com/2020/10/presentation-state...

Sure, it's definitely _peaked_, because there's a lot of other great options in the React ecosystem these days. But, there's still plenty of good reasons to use Redux. And, with our new Redux Toolkit package and the React-Redux hooks API, "modern Redux" code is a lot different than what you've seen in the past, as shown in our new "Redux Essentials" tutorial:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

Can you run code written in 2015 on the latest version?

Not necessarily; just offhand I remember these: https://reactjs.org/docs/react-component.html#legacy-lifecyc...

Admittedly those are trivial renames, but they've been renamed as such because they're very likely to be buggy with async rendering.

bwahahahahahahahahaha

Organizations love the churn because they can get away with age discrimination lots of well qualified devs are left out to starve to death while constant churn hides a system designed to filter out the most experienced.

That hardly makes any sense. Most widely used frameworks are open source projects; it seems much more reasonable to assume that constant changes in direction are more an expression of developers wanting to play with the fancy new toys instead of sticking with one paradigm and keeping it stable.

Even setting that aside, there's nothing keeping older developers from switching to a newer technology; it might be a bit bothersome to adapt to ultimately inconsequential changes again and again, but that applies to younger devs just as much.

It's also not like web development is old tech in any way. There's constant improvements being made and things are often changing for the better.

Well, for the most part at least. Looking at the situation with serverside resource compilation I have to wonder when the world of web will re-invent make and call it a revolutionary achievement.

That's a very strong statement, do you have anything to back that up?

I think the problem with bespoke frameworks is that many career driven developers won't want to become a specialist in proprietary tools that won't transfer. However...

I have this strong suspicion that most projects that use something like React don't really need it. Like, if you're creating something that actually acts like an application and data might be shown in many places it makes a lot of sense, but for something that's just displaying data from a db on a page hit it can be massive overkill.

Thanks for reading - original author here. For the precise quote you mentioned I came up with somewhat format rules which prevented building a framework (code-wise) for this case study. The "caveat" you mention is just an explanation for the chosen ruleset; I believe I haven't introduced any general-purpose DOM/UI code in the case study and instead only describe patterns (correct me if I'm wrong!). I agree with your view of framework value as I professionally use React on a daily basis and will continue to do so, for similar reasons :)

Using frameworks is far more about hiring and human resources than technology I feel.

However, if your "micro framework" follows language idioms and is thin enough you get the best of both worlds, whilst releasing yourself from some of the downsides that come with using a general purpose framework.

Frameworks make hiring a bit easier it's true.

I'm amazed at the number of developers who can't seem to cope with working with custom in house frameworks. I'm talking about fully working systems, with full source code and being walked through the code by the author / maintainer.

They fall apart, constantly complaining that the approach is non standard, deprecated, dangerous, unprofessional, untestable.

So we are trying more and more to use frameworks, just to be able to hire more easily.

This just displays the core incompetence in basics that many devs who are dependent on frameworks have.

Definitely agree, developers can get away with a lot of missing knowledge and not realise it, if they're using frameworks from the start of their career.

Ideally you could hire senior developers with the skills to work inside boutique software, but I have found "legacy" code turns a lot of people off a project, and most boutique software eventually gets called "legacy" even if it's well architected and running perfectly fine.

The skill which I think new devs could differentiate themselves with, is debugging. Familiarising yourself with software patterns definitely puts you ahead, but being able to use debuggers to understand code that has no pattern, that's when you become the kind of bug-squasher/problem-solver that projects like that require. If you have good debugging skills, you can work on any project, because you can find out all the information you need by stepping through the code.

With es6 template strings you can do a lot of heavy lifting with some very simple code. This example still uses es5 to mr that’s insane who on the web is still using ie6?

IE11. IE11 remains the problem.

In the corporate world, yes (sadly), but for personal and free projects I'd say it's acceptable to just ignore IE entirely and at most include some JS snippet to tell its users to get a real browser.

IE11 is an unsecure browser and doesn't even support numerous HTML5 security features. Any business that still relies on IE11 is asking to be hacked, no more, no less, because it also means that these businesses are still running older versions of Windows.

Now IE11 isn't even an excuse because $current_year ES version can be transpiled to older ES versions.

Can I claim I don't violate the "No general-purpose utility functions related to the DOM/UI" if I use only one such function? O:) https://github.com/stefanhaustein/notemplate (the demo is just TodoMVC, though)

:D just to be clear, the rules were made just for the case study. I'd never recommend following these rules in a professional project. They are part of the method of the case study, not its outcome; the outcome is a couple of (hopefully) interesting patterns and insights, without trying to prescribe anything.

> adopting an established valid opinion to guide the team's development

Different requirements allow for different settings. Coming from an Enterprise Application background, I found this being more often the case or the only case. Working with different teams, developer fluctuation, different time zones, different skill sets, a framework guides the development process far better. Vanilla JS is something that should be avoided in team setups. There is too much mental overload that is usually not justified by the benefits. It is like deliberately choosing assembler language when Java or C# would do the job better. Frameworks got a bad rep. For me, they are tools that should be used.

I've heard the Assembly vs. C analogy a couple times now, and find it hard to apply:

Assembly languages come in many flavors whereas C is a single, standard abstraction over these.

DOM is a single, standard API whereas frameworks/libraries come in many, ever-changing flavors and provide different abstractions over the DOM.

It's a very different situation. Also, the level of abstraction that C provides over assembly is amazing. The level of abstraction that React provides over the DOM is comparably low (they are based on the same programming language).

I have experimented with something like this for a new side project. The plan was to have a TypeScript class for each component, and a render function to render them on dom. Then the listeners would be handled directly via addEventListener. Eventually I started having thoughts like - "maybe I could have the render function parse attributes and auto-attach dom events".

It became obvious it would become a side project of its own and not a smart use of my time. I settled down for Svelte and I love it.

Of the three you listed Vue is the most 'opinionated' in that it ships with official router, official store (vuex) etc and that is a huge deal.

With React and particulary svelte (for now) it's a mishmash of possible choices.

Where that bites is when you have 3 choices to make with 4 options.

4^3 === 64 - so any project you pick up/come onto has a 1/64 chance of using a stack you've seen before.

True, but routing libraries don't tend to be that complex. Picking up a different is not exactly a big deal.

Reply on news.ycombinator.com