@jmclaren As a publicly traded company we're limited in our ability to share our full roadmap
Ironically, I've done a lot of trades on HubSpot's stock... No idea why I didn't realize that sooner. That's fair.
Do you plan on adding other event types to workflows? Page events. Hooks prior to publishing.Do you mind elaborating with some use-cases you're thinking of? "Page events. Hooks prior to publishing" makes me think of possibly 2 completely different things and I want to be sure I understand your intent.
Sure this is fairly straightforward. Page events that allow a "hook" into how things become "spit out" by the template rendering engine / prior to being cached would be immensely useful and imo goes a very long way to fixing the vast majority of problems with HubSpot sites and development problems overnight were this released. All you really need is to open up the page events API / files via the webhooks flow. You should have most of the items available to do this already without too much technical debt.
I'll give you very clear use cases with utility:
1) Critical CSS
2) Injected table of contents
3) Injected meta / schema if the page is able to be parsed via workflow hooks / shoot off some webhooks -> re-inject things prior to publishing.
4) Events for push notifications on publish (new posts, ...)
a million other use cases....
Currently doing simply things like this is very contrived and even impossible for 3). To do 2) you either need javascript which is a horrible solution for this or to track an entire registry via hubl and inject it at the end of the template / rendering process amongst other things. Critical CSS is an automated process... nobody should be doing critical css on a case by case basis. Dependnet on level of control... you could even do name manging and splitting.
My point here is a lot of the problem with HubSpot development is this lack of control and ability to interface and do things that are incredibly easy on other platforms. The reason all of this is possible on wordpress and other platforms is simply because their developers have the ability to use PHP and other languages at this level. It's not intrinsic to the platform itself or anything that's "magic".
This goes back to 1) about programming languages and the ability to interface with the CMS on a lower level and do this and 2) performance problems. So, with the lack of this page events would essentially open up a "plugin" ecosystem that could fix some but not all of this. Really most of the things I've listed are part of the same problem.
But even that's still not good enough. You really need the ability to use a language / lower level interface to do the vast majority of things that are actually useful. As stated previously, sitemap management, feeding, and a plethora of other use cases. Let's reframe this also if you're not seeing it:
I as a client pay $$$ to use the platorm to inevitable inherit the problems below, but beyond that I also don't even control my own site map, can't manage my syndication, and can't even hire someone to do it or me.
What if I had a russian audience? What i I wanted to target Yandex and needed to manage the way my feeds and sitemap are constructed per their requirements. What I have a big target audience that uses, say Feedly, and I can't target that?
So what are you supposed to do? Do I pay for screaming frog / pay for multiple different services to manage all of this to fix platorm imposed problems at which point why am I wasting all of that money to just pay more money to "patch" all the problems I have?
See my point? What value is there in a platform that requires fighting such an uphill battle constantly from every development aspect - in the platforms current state.
Obvious problem: Determinism / locks. But, there are ways to handle this. If there's a single feature that should be added.... It's this one.
Re: Performance list. Not going to quote that behemoth wall of text.... Yes all of those are available and some of them have been for quite some time. But, many of those features are masking underlying problems. Others I wouldn't really consider an "improvment" rather than the "bare minimum" according to standards. Yes, there are complex and in many cases convoluted performance optimization techniques you guys can't achieve reasonably - within a bundled CMS - but there's still room to improve here... You guys are going to run into a big problem when HDR specs are completed and HDR is feasible on the web fyi.
Re: Fast pace of evolution. Entirely correct. This is also why themes need to be opened further for developers and my final point here are required. There's no way you guys can keep up and even if you could.... It's still suboptimal. In fact, I'd go so far as saying most of the recent product "improvements" have actually been steps back. So, I'm not confident in this nor would I suggest other to be.
You specifically mentioned forms. Forms are unique in that they require a lot of state management, error handling, and we have features like progressive fields, dependent fields, you can even place images in your form, we have all of the underlying input field types. It's a lot and it's critical that it's backwards compatible to a lot of different browsers otherwise folks could lose out on sales. The forms team for awhile now has been looking deeplly into the code they render and control, I don't have specific details to share at this time. I'll pass this feedback on to the forms team. In the meantime if you are dissatisfied with the performance of the forms you are welcome to use the form submission endpoint to roll your own form, just understand you then must handle the error handling, dependent fields, etc.
If you see another opportunity for something we can do to improve performance even further definitely submit it to the idea board. We're always looking for more ways to make CMS sites even more blazing fast.
The real problem with forms is CLS shift, same with CTAs, due to their asynchronous nature - naturally. Currently if you want to fix that it's a case by case basis.
Beyond that... coming back to the original question, I believe between this, the cta, and other scripts loaded it's roughly a half megabyte worth the javascript....
Edit: Actually the v2 forms alone is 500 KB.... Let's reframe this.... To load a few forms on my site... I need to load a script that's the equivalent of loading dozens -to hundreds of optimized images (ranging from webp to small svgs).
A lot of this has to be bloat. I cannot fathom any JavaScript file that is 500KB doing something as simple as rendering forms regardless of their complexity or dependencies. Bundles styles, i18n, etc are included within the JavaScript bundle for forms regardless of need. That alone would significantly trim the size. What website, outside of external embeds, doesn't style the forms and necessitates bundled styles?
Especially with themes..... Obviously, not familiar with the stack or what happens on a lower level, but at a glance I fail to see how this necessitates being bundled outside of third party integrations. If it's not international.... why the i18n? Sure, maybe you have one form on the page that's embedded and one isn't.... But, that's extremely rare and obviously erroneous if someone is using both and even then you could just grab the split in that case.
There are plenty of techniques here and most companies employ them. I'm surprised you guys aren't already doing this. It's incredibly common to do code splitting in this manner by serving `/localized/` paths to assets with only the necessary bundling. And that's just a start...
This is common amongst all HubSpot assets served to clients. Poor code splitting. Last time I looked at the CTA file I believe there were redundancies being served that could be trimmed, but it's been a while. Regardless the bigger problem with CTAs and these assets is dragging out the waterfall and clogging it by injecting per element.
Let's reframe this also....500 KB to load a ew orms on a platform that touts i18n in which many of these regions are still 2G connections.... Also just a lot of data for little gain.
In the meantime if you are dissatisfied with the performance of the forms you are welcome to use the form submission endpoint to roll your own form, just understand you then must handle the error handling, dependent fields, etc.
This is actually my main point of the entire thread.
Currently - and actually for the multiple years people have been bringing this up - the "solution" has always been "well don't use it" in which case what value is this providing / does the platorm intrinsically have to anyone if every platform feature, supposed to be providing value, necessitates having to not use it in order to have a website that's on par with expected standards? That's rather paradoxical.
For modules: Critical chaining requests -> kills web metrics -> just don't use it! Use a modules css ile or a main bundle.
For CTAs: Use tracking links or the API instead
For forms: See above
List goes on....
I even have wordpress / other clients that try to use hubspot forms via 3rd party and eventually have to drop them because it mars their websites so badly.
It's a very hard balance to achieve, and our competitors have often simply picked one audience or the other. We want to be different in that regard.
Yes it is, but that balance is exactly what's stunted the CMS and will continue to do so. At some point you're going to have to pick - and you guys are already very behind your competitors. Realistically, who builds everything? The devs. I cannot count the number of people that cannot do even basic text editing much less actually managing their site to any reasonable level and if I, as a dev, have to come in when a marketer finally gives up and hires someone to do the hard stuff... well at that point I shrug my shoulders, go "this is a mess", and don't bother. These approaches severely over estimate peoples capabilities.
This leads into various discussion threads across the forum - can track down if you want. To summarize, from the marketing side.... I see your point it's a hot sell to marketers and a "good" feature to have, as a company you need that, but it's horrendous in the long run. 1) Simply because it empowers the wrong people due to the previous and 2) it causes client websites to become an asset that inherently loses value and gains entropy because marketers don't know what they're doing - no offense to any that's not a jibe but a simple statement that it's not their domain of expertise - and as we very well know the web is complicated with complex standards. Especially with all the new web tech coming out.
Here's a way to reframe this:
Is this approach actually valuable or provide anything of value to anyone - developer or marketers? It doesn't - at all in my opinion - quite the opposite.
For the developers it's horrible on every facet due to 1) lacking control due to trying to balance this and ending up with something that's halfway there or both parties and 2) always inherting a mess when marketers eventually break down and hire someoen to do the hard stuff.
For the marketers... looks great on the surface as described. But, again lacking experience and no idea what the implications of their edits are, so eventually marketer / owner goes "wow this is bad, we have no good web metrics, ..." and ends up hiring a dev anyways. Much less wanting to add anything even remotely modern.... color schema etc. So, with all their free-form editing provided to them they build a subpar site with significant problems they're not even aware of. Then, the dev has a very limited feature set to work with for improvement and can barely improve anything despite their skillset, because of the restrictions.
None of these things, on any platorm that has ever tried to do this, has ever worked. It's why people still hire "divi" developer, "wix" developers and all of these developer "types" for the simple reason that it's too complicated for people to handle that aren't technical - even your platform in it's very basic state is too complicated for marketers. And, to be frank, Wix and other editing interfaces are not even in the same league as you guys. So, i people can't handle a very smooth modern editing interface there's little chance there handling HubSpot's much harder to use variant.
So, as a client here's where I'm at in this process: I start off with hubspot -> buy their packages / cms, etc -> pay loads of $$$ -> everything looks good or the first few months -> I start noticing problems when I start paying attention to search console and actual metrics -> try to hire someone to fix it pay laods more $$$ -> they can't or achieve it in a subpar fashion, because that's all they really can -> maybe I try this or months on end paying $$$ and lots of time and effort to achieve something so basic / minimal that would have taken < 2 hours on WordPress -> eventually give up bite all the $$$ I've wasted and move elsewhere to rebuld my entire site to achieve what I couldn't.
That's incredibly problematic and disheartening.
I have had countless clients go through this process - inherited projects where they have - etc and every last client eventually goes "hubspot... yikes" let's move to platform X due to this. Beyond this, as stated, no developer can reasonably recommend this. A large problem with client outcomes and "developers" on HubSpot is it's marketing.... It's marketing agencies that aren't development shops - despite what they may think - and tend to pump out subpar quality technical assets for their clients in some "bundled" package with severely lacking standards and nobody in house that has a relevant skillset.
So, 1) bad interface, 2) bad control, 3) bad dev. experience, 4) bad assets for clients, 5) bad technical resources / agencies compounding all the previous. A developer focus also helps "wash out" all of these so called "developers" and subpar outcomes. It's harder, but in the end everybody wins except maybe said marketing agencies - which I'd personally consider a bonus. But, this comes full circle with who exactly HubSpot's client base is 😉
Bonus: Editing interace / rich text editor is incredibly annoying to use sometimes. Example being automatic insertion of <p>'s when used as a image insertion block. Yes, I agree that's a poor usage, but again marketing standards not dev standards.... so it happens. And it immediately breaks the nice flow / alignment of the grid. Obvious solution would be something like p:has(> img) + p:empty but that's not the best way to go about this. Adding some safeguards here would be helpful.
Beyond that.... Developers really need a way to hook into the rich text edtior beyond removing things. We need to be able to add things. Footnotes, references, stock tickers, etc possibilites are endless. Being a dev... obviously I see the technical limitations here and the JSON representation is already massive for what's already included in terms of feature sets, but regardless.
@jmclaren
Edit: Extra bonus.... i18n **bleep** for various reasons the least of which being the size of bundles... But, also in terms of hreflang and other writing system / path management.
You don't always want to denote hreflang / alternate language variations according to languages... Look at Apples homepage as one example. Their approach is incredibly common. They target english as it's spoken in latin america via `/lae` paths mapping to `en-(REGION)` variants. There are similar approaches people very commonly us
You can actually do this through some hacky methods... And in this case it's actually a bonus you guys don't do anything of value in the sitemap such as indicating alternate langs otherwise this wouldn't work 🤣
I touched on the highlights here.... So, while you guys are attempting to "strike a balance" what you're really doing is providing nothing of value or to a degree of utility.
.png "HubSpot Employee"){kind=icon}
