> So your point is that you don't really know, but let's blame them for trying, or what?
I think GP's post is that _you_ don't really know the landscape which was why you reinvented the wheel, which I tend to agree with. You even agree with this unless you're being rhetorical here, no?
> Which functionality?
Let's take a look at every feature we see on the next.js page (https://nextjs.org/):
Zero Config
Automatic compilation and bundling. Optimized for production from the start.
Hybrid: SSG and SSR
Pre-render pages at build time (SSG) or request time (SSR) in a single project.
Incremental Static Generation
Add and update statically pre-rendered pages incrementally after build time.
TypeScript Support
Automatic TypeScript configuration and compilation.
Fast Refresh
Fast, reliable live-editing experience, as proven at Facebook scale.
File-system Routing
Every component in the pages directory becomes a route.
API Routes
Optionally create API endpoints to provide backend functionality.
Built-in CSS Support
Create component-level styles with CSS modules. Built-in Sass support.
Code-splitting and Bundling
Optimized bundle splitting algorithm created by the Google Chrome team.
Now, do you want some or any of these things? How long do you think it will take to incorporate them into your new tool which you just rolled from scratch?
I guess at this point I'll add in some opinionated views here. At a certain point along your software engineer journey towards becoming a senior engineer, you are supposed to understand that undifferentiated heavy lifting and implementation is a bad strategic move in terms of technical strategy. If I am your CTO and you are telling me that you want to write your own Intercooler-esque library and move all of our core frontend checkout code away from React (an ecosystem with conventions that much of the rest of the world uses) and towards a proprietary solution I am going to ask you for a good reason. That is to say, I am unlikely to be persuaded by "I didn't spend enough time deeply researching how the rest of the ecosystem's users handle these issues" and I am likely to gently remind you that we will likely get more mileage out of investments that make our user experience better rather than scratching the itch to write a new framework.
> Here is the news: we will never add them to the new tool. No TypeScript, no compilation, no routes, nothing.
I think that's part of the issue. You have built something outside of an ecosystem. Have you planned for what will happen after you leave? Have you been on the receiving end of inheriting a codebase written in a language (like ClojureScript) that was buzzy for a while but then never took off? It happened to a lot of people with Coffeescript.
> Good news you're not, right?
Are you sure that's good news? Because what I see here is a poor choice of a niche language (ClojureScript) which lacks traction and will probably die long term. Moreover, because it lacks an ecosystem (or more accurately, that ecosystem is not the exact flavor you want), you've taken liberties to write things completely from scratch. Why not use Next.JS? Why not use Rails + Turbolinks? Why not reconsider writing crucial infrastructure from scratch when it already exists in many forms? Most damningly, why should you be trusted to reinvent the wheel if you lack the patience or thoroughness to go through previous solutions to this problem and put together a convincing argument for why they fall short and you need to make something new?
These technical decisions around infrastructure, stack and ecosystem are ticking time-bombs. They are almost certainly a long term technical risk and an eventual roadblock to recruitment/onboarding. I think it's unfortunate that you have wasted your time reinventing problems that have already been solved instead of focusing your talents onto areas which deliver more value to your customer. As you are working on e-commerce, this could be anything from marketing and demand acquisition to checkout funnel conversion to fulfillment, up-selling and cross-selling.
If your organization's leadership incentivized engineers to seek these kinds of investments, it would probably result in you choosing a stable stack (which, while imperfect, is good enough, has a larger ecosystem of maintainers than just the company, and so has less of a risk of blowing up in a few years) so that you could focus on investing into more customer-centric engineering. It's a shame because I think that this kind of engineering is the kind that helps engineers grow and mature in seniority. It gives them the capability to become technical and people leaders, who are exactly the kind that most companies that employ leaders need to have.
But that can never happen when engineers don't develop the judgment to determine which problems are strategically valuable to the business and which ones amount merely to overhead. And of course, many companies see no need to invest in or to empower their engineers this way, so this kind of thing keeps on happening because you need to work on something stimulating or what would be the point of work? Feel free to disagree, but based on what I've seen, I think you are working on the latter. I guess all I could ask you is imagine what kind of amazing results you and the company would see if you focused all that incredible energy you put into this infrastructure into delivering customer value!
I think GP's post is that _you_ don't really know the landscape which was why you reinvented the wheel, which I tend to agree with. You even agree with this unless you're being rhetorical here, no?
> Which functionality?
Let's take a look at every feature we see on the next.js page (https://nextjs.org/):
Zero Config Automatic compilation and bundling. Optimized for production from the start.
Hybrid: SSG and SSR Pre-render pages at build time (SSG) or request time (SSR) in a single project.
Incremental Static Generation Add and update statically pre-rendered pages incrementally after build time.
TypeScript Support Automatic TypeScript configuration and compilation.
Fast Refresh Fast, reliable live-editing experience, as proven at Facebook scale.
File-system Routing Every component in the pages directory becomes a route.
API Routes Optionally create API endpoints to provide backend functionality.
Built-in CSS Support Create component-level styles with CSS modules. Built-in Sass support.
Code-splitting and Bundling Optimized bundle splitting algorithm created by the Google Chrome team.
Now, do you want some or any of these things? How long do you think it will take to incorporate them into your new tool which you just rolled from scratch?
I guess at this point I'll add in some opinionated views here. At a certain point along your software engineer journey towards becoming a senior engineer, you are supposed to understand that undifferentiated heavy lifting and implementation is a bad strategic move in terms of technical strategy. If I am your CTO and you are telling me that you want to write your own Intercooler-esque library and move all of our core frontend checkout code away from React (an ecosystem with conventions that much of the rest of the world uses) and towards a proprietary solution I am going to ask you for a good reason. That is to say, I am unlikely to be persuaded by "I didn't spend enough time deeply researching how the rest of the ecosystem's users handle these issues" and I am likely to gently remind you that we will likely get more mileage out of investments that make our user experience better rather than scratching the itch to write a new framework.