I (thankfully) don't have to use Salesforce very often. But from my experience, the Lightning Experience always felt non-performant compared to the traditional server-rendered pages. Things always took a noticeable amount of time to finish loading. Even though the traditional interface is, by appearance alone, quite traditional, as least it felt fast. I don't know if Lightning's problems were with poor performing front end code, or poor API performance. But I was always underwhelmed when testing the SPA version of Salesforce.
One of the bigger mistakes Salesforce made with Lightning is moving from purely transactional model to default-cached-no-way-to-purge model. Without letting a single developer to know that they did it, what are the pitfalls or how to disable it (you can't).
WRT Lightning motivation, sounds like a much better option would've been supplement older server-rendered pages with some JS, update the stylesheets and make server language more useable. In fact server language is still there, still heavily used and still lacking expressiveness so badly that it's 10x slower to prototype on it rather than client side JS...
I was using SFDC extensively when the Lightning experience first arrived, and my experience tallies with yours. I ended up switching back to the old experience to get my day to day work done.
The vast majority of Salesforce code is "legacy", so you don't get a lot of people sticking around that know modern web stuff.
I saw the same thing happen at a previous employer. Nobody that knew modern web development would stick around and let their skills rot, so our "new SPA" interface was build by a team that only knows jQuery
Why do they insist on forcing their framework of the week on their dev community and make it much easier to bring your own framework? NIH syndrome? Lock in?
We use react and visualforce to get our products built but the visualforce requirement to do so is sub optimal.
At its core, Salesforce is a platform. As such, our customers expect their code to work for the long run (and backwards compatibility forever). Not owning the framework fundamentally means jeopardizing our business and our customers, since we can't control our future.
We believe the best way to future-proof our platform is to align with standards and help push the web platform forward, hence our sugar and take on top of Web Components.
Also to your comment about using different frameworks, again as a platform, allowing our customers to trivially include their framework choice of the day, will mean that we might end up having to load seven versions of react, five of Vue, 2 Embers .... You get the idea :) Outside the platform we love all the other frameworks (hence other properties might choose what it fits their use cases) and we had a lot of good discussions with framework owners about how to keep improving things over the last two years.
Our goal is to keep contributing to the standards and push all the things to be implemented natively on the platform so we all get faster and better.
So fork a sanctioned version of React or some other framework, why reinvent the wheel? Just fork it and call it ReSales or something like that, stick with the baseline and then if FB moves in a direction you don't like, then move your fork in the direction that best suits Salesforce.
> So fork a sanctioned version of React or some other framework
They have basically done that by making LWC a pure ES6 implementation. If you look at how one authors LWCs, then you'll see that you're very much at home if you have worked in React or Angular using JS or TypeScript. It's basically, conceptually the same as those other frameworks and all your JS experience applies.
The difference is all the styles and widgets that make their JS library (called Salesforce Lightning Design System (SLDS)), plus all the decorators and how they work.
Here's why I think that Salesforce should be praised for the direction they have taken in the last two years or so...
They have completely revamped and sped up the Lightning UI so that speed is not an issue anymore. They have also flattened their authoring environment to ES6. To get this done, they have taken the bold step of dumping their old Lightning (Aura) framework for this new LWC framework.
That means if you're an enterprise who's invested in the old Aura-based framework, you're basically screwed and now have a dead codebase. But, it also means that no one has to use that old, crappy framework anymore.
And, here's the most important thing that Salesforce has done to bolster it's own ecosystem. With Lightning Web Components, if you are looking for Salesforce devs, it's now a lot easier to hire SQL-savvy Javascript devs who can adapt their React experience to LWC.
No, open source[1] and free software[2] are the same thing. The only difference is in philosophy of advocacy - the open source movement branched off from the free software movement because they wanted to emphasize the practical benefits rather than the ethical aspects (user freedom).
If you look at the definitions I linked to, you'll see that they are very similar to each other and both involve a lot more than "just means you can view the code".
In fact, the very first sentence of the introduction explicitly rejects your proposed definition: "Open source doesn't just mean access to the source code."
The big issue is browser support. According to caniuse, IE and Edge simply have zero support while Opera and Safari have only partial compliance. The current Firefox ESR doesn't support it either (behind a flag).
The polyfill incurs a big performance hit and a lot of devs need to support those browsers for several more years.
That's silly, customized built-ins are not an essential feature. They are a nice to have. You can get by without ever using them, which is indeed what most people do. As does the subject of this discuss, the Lightning Web Components doesn't use that feature at all.
It also means, that you cannot use existing form controls for your custom element, you must build them up from scratch from divs, and relegate them into uncanny valley of not-quite-native, slightly-off elements.
Yes, it is possible to not use them; you can always make your life harder than necessary, you could also write an modern OS in assembly, for example, if you wanted to. If people are avoiding them today, one reason could be that they want their components to run in Safari.
Even if you aren't able to inherit from a form element, can't you still `createElement` one and add it inside your custom element? Surely they don't force you to reimplement <input /> from scratch!
Yes, you can compose them; and then implement a proxy that creates all the methods and attributes that given element class is supposed to have and forward them to the real implementation.
Busywork, so Apple can hold their position. How nice. No, it is not "perfectly fine".
I don't see this changing much. Salesforce has a serious follow through problem. They tend to half-a$$ good ideas and then once they get the press for them, they stop investing in them.
Just tried the create-lwc-app and it didn't build finish properly
<template if:true={isTrueTemplate}> Sorry been down this road with Angular before, logic in the template is a dumpster fire of a non-debug-able, bad idea.
I haven't used it, but I'll try to summarize what I know for the folks asking general questions.
"The Lightning Experience" generally is a set of related products and tools from Salesforce. It's based on a live-updating model (as opposed to Salesforce's old-style whole page refresh model) and has a new visual and UX design system targeting mobile.
They're trying to bring everyone along to their new model, but they clearly understand it will take a while: they've built an experience switcher in the main menu and have invested heavily in adoption tooling.
The honest truth is that Lightning Components are just vendor lock-in. Once you buy into lightning, you wind up using their proprietary communication channels and their proprietary component library (which this press release makes clear isn't open sourced).
If you want to change backends to something better, you can't because while the backend will port rather directly, the front-end will not.
Then there's also the fact (unless things have changed dramatically in the past few months) that writing your front-end in Vue or React will result in much faster UI experiences and finding developers to maintain it will be easier and cheaper (Salesforce devs are generally a bit more expensive).
I think the honest truth is that the only people going to be using LWC are Salesforce developers on the Salesforce platform, they're already locked in.
> live-updating ... as opposed to ... whole page refresh
Does that mean that changes in data on the server are automatically pushed to the client, i.e. if you're viewing a customer and someone else is editing that customer, you will see the data in your view change in real time?
Or is it just using AJAX instead of traditional server-side rendering?
Question for the HN crowd: is your company using, or have you used Salesforce? On what scale? What kind of business? Was it worth it? Did you enjoy the experience? Does it make sense for smaller businesses?
I have considered it for my company because it can do some neat things, but I feel a bit overwhelmed by it. Really curious about the feedback.
I used it quite a bit for a 3 year period from 2011-2014 or so. I imagine it's changed a bit since then (but it didn't really change that much in that time period, so I wouldn't imagine that it's completely different since the last 5 years). Overall it had an old VB5 feel: you could do simple things _really_ simply, but difficult things were more or less impossible, and even if you wanted to step out of the infrastructure and do the difficult things somewhere else, integrating back into Salesforce was still a major hassle and often not worth the effort.
At its core, it's sort of a dynamic form builder: you design your data model and Salesforce creates input/entry forms for the data objects in the model. If there's a one-to-many relationship between two objects, when you edit one, you see a list of the related objects, and you can do bulk operations on the list in place. You have some customization options but for the most part, Salesforce creates all the UI for you and because it's uniform, it's easy for users to work with.
The two biggest problems were limits and opacity. Salesforce imposes limits on how many operations per second you can perform like reads or writes, and its not usually easy or even possible to predict what limits you're going to bump against, so you end up discovering them through trial and error (in production!). The other problem is the opacity of the platform - it's working a lot of magic under the covers and you have no visibility into what it's doing and definitely no control over it. If you thought Ruby on Rails was hard to reason about, just wait until you meet Salesforce!
All in all, I'd recommend doing as little "in Salesforce" as you can realistically get away with - your users might demand it because they know it, but Salesforce makes you feel like you can run your entire business in there, but those are murkier waters than you would imagine.
I work for a small business(~50 people) and we use Salesforce more or less across all business functions. I've been with the company for nearly 4 years,so I witnessed a lot. Salesforce is a fantastic platform,if used correctly. It's worth it. It does make sense to use it for a small business. Salesforce can be as big or as small as you want it to be.If you are small business with small needs,keep it simple and use it to track sales.If you are business with complex needs, do tons of customisation, integrations and etc.
I work for the federal government. Another team in my organization is using it for contact management and some other CRM tasks. They are very happy with it. My team is developing a custom dashboard prototype for leadership. Our results are mixed. Please note that I've only been working on this project part time for about 4.5 months, so I'm far from an expert.
Basic entry and view forms are very easy to create; Basic reporting is very easy, as well as basic charting. But the provided charting components can only be customized up to a point. For example, you can set the color of chart segments by value for pick-list fields, but not for calculated fields, and only for certain types of charts.
Salesforce is a big, complicated system and it takes a while to learn. If your needs can be met by their built-in Sales or Service modules then it may be a great choice. If your needs can be met by a 3rd-party add-on, and you're willing to pay extra for that, it may also be a good choice. If you want to recreate your custom business logic in Salesforce then you may want to hire a consultant.
Salesforce also has a lot of pricing and licensing options, so you would need to be careful about making a purchase before you know all of your needs and understand the different license types and pricing tiers.
Salesforce reporting is relatively basic,consider Einstein Analytics for more advanced stuff. Alternatively,just connect it to Tableau and do all the fancy shpancy stuff there.
It ain't too pretty, but instead of creating of thousands of workflow rules or spending days clicking, you can simply use spreadsheet to decide how your logic runs.
Salesforce has been a terrible experience with our company. I'll focus on the customer support / service module since as a sales platform, it definitely shines, but as everything else it falters. Lightning, the "new" experience that kept being touted as the solution to our existing problems, has been even worse -- it is incredibly slow and bloated. I have to restart my browser periodically since it starts taking up 2-4 gigabytes of memory in Chrome. The interface feels like it is stuck in the past, being unable to use native tabs in your browser and forced to use their tab implementation. Everything feels clunky and slow. The API to use things is pretty awful and obtuse; the code for custom components is insanely verbose for the simplest things.
The marketplace is insanely expensive to add simple features or tools that many other platforms have built in -- or, if not built in, easily developed with a sane API. Look at this sample project for a session timer to get a feel for the insanity: https://github.com/SalesforceLabs/CaseTimer and things like a command line interface and source control for your sites are either nonexistent or poorly supported or documented.
The only reason we use it is because the directive came from above; Salesforce feels like Oracle to me in that it gets sold to the higher level execs who never actually use it, and it gets forced on everyone else.
I know there are some good Salesforce sites around somewhere.. but those seem to be the ones where they've replaced all the Salesforce stuff with their own UI and simply use it as a backend database.
I work for a marketing agency that is also a Salesforce partner. However, I only do Salesforce Commerce Cloud. Or is it B2C Cloud nowadays? There's been a few rebrandings since I started using it. It was originally Demandware, and we liked it that way!
We have a handful of clients we build and maintain sites for. Some older, some newer. I don't have exact numbers, but if a vendor isn't pushing $5 million+ annual sales, Commerce Cloud doesn't make sense.
When I started, code was tied together with "pipelines", which were basically flowcharts[0]. (Newer sites use a controller model.) Later on, new sites had a modularized JS and SASS system held together by node.js scripts, along with tightening PCI requirements (TLS 1.1/1.2+, 2 factor auth required for code and asset uploads (client side certs with WebDAV)).
The front ends are tied into Cloudflare automatically, and the back end has always been through a highly restricted ORM. The whole platform is laser focused on e-commerce, and as soon as you step away from the strict add-to-cart/wishlist and checkout model, the platform is horribly suited. It doesn't do newsletter management, reviews, or address deduplication well (better to integrate with external services), and file/image uploads are a pain in the ass. It only has enough CMS features to sell things; you can use it as a corporate blog, but it's not that well suited if you have a marketing department that changes everything and wants something "completely new" on a weekly basis.
I've had a good experience. For the times we've needed it, Salesforce support has been effective.
I've never used it myself (edit: oh, wait, that's not actually true, though it was years ago), so I can't answer some of your questions. However, I have done a fair amount of Salesforce consulting and can give you that perspective. I'll speak in absolutes but I'm sure things are more nuanced.
For established companies of a certain size, Salesforce is usually just assumed to be present, kind of like IBM in a previous era. This is mostly because everything integrates with Salesforce, and all salespeople know how to use it.
For smaller companies, particularly startups, the ROI isn't as clear. Salesforce is expensive. The CRM that most startups need is marketing-focused, and you probably get one for free with whatever marketing automation tool you use. It's worth it for smaller outfits only if they have a long and involved sales process (say, institutional sales primarily), and perhaps if you are involved in education or a non-profit, since they have programs that reduce the cost in that case.
Salesforce out of the box isn't particularly enjoyable to use, but it's learnable and usable. A lot of companies add on cut-rate customizations that end up making things a mess, but that's more a commentary on change management at large organizations than the platform itself.
To be honest,I never understood this argument that it's expensive. The enterprise version,which is essentially the bare minimum for any business that is more complex than a lemonade stand, is about $100/month/user. I'm talking about western countries here. If a business can't spend that kind of money on a user,it's time to have a think on whether it needs a CRM software or new business model. Also,if configured well, it can hike up efficiency by quite a lot. We do twice as many booking as we used to do with the team remaining the same size.
If you are considering this and it’s a small business, please consider Retool (https://tryretool.com) or something similar. The thing with SF is that it’s way too big for starting small and it’s hard to customize when you start getting bigger. You don’t need more than a couple of SQL tables to have a basic, simple, CRM and you own the data that you would be able to easily analyze in your favorite dashboard tool.
We used it for some years in a startup as a sales tool but it was very very slow and the UI and flow was too complicated for our needs. So we switched to Pipedrive which did the job, was a great success and for our usecase was much easier too use.
I worked for a roughly ~80 person B2B SaaS startup whose primary product was a Salesforce managed package tailored to a specific industry. We had around 8000 customers at the time I left the company.
Salesforce as an internal sales-team-management tool is a very different beast than Salesforce as a product delivery platform, so I'll try to address both.
As an internal tool to manage a sales team, Salesforce shines. It provides a simple, extensible UI for sales reps of all skill levels to coordinate their activities, and provides lots of hooks for integrations of various other products. For example, our marketing team generated leads using other software, and could easily pipe their lead data into Salesforce, where it was easily acted upon by sales reps. Salesforce quickly became _the_ source of truth for the reporting activities of the sales department as a result of the ease of getting data into it. Additionally, Salesforce's customizability was a huge asset - when the sales team wanted to add fields to their core CRM data tables (Leads, Opportunities, Contacts, etc.) - they could do it themselves without involving the engineering team at all, because Salesforce's configuration-first interface enabled them to do so. Eventually it got complex enough that a full-time Salesforce admin was hired, but for smaller teams that might not ever be necessary. Salesforce can do a lot more advanced things if you add custom code to it, too.
As a platform for delivering products, it has a whole litany of problems that make it difficult to work with, so I wouldn't recommend using it for that purpose unless you have someone around who has adequate experience to avoid the pitfalls. Salesforce "orgs" are essentially primitive containers - they're instances of the Salesforce core product that are isolated from one another on a multitenant cluster infrastructure. A managed package is essentially a custom configuration for the Salesforce core product - including database schemas, permission assignments, custom code, and more. When you sell a managed package, it is installed in your customers' orgs and all custom code is obfuscated from their view. This is a neat solution for preserving IP, but it can cause huge headaches when your customer base grows. Without adequate preventive measures, customers (used to the customizability of Salesforce) might build their own org-specific customizations that rely on functionality in a specific version of your managed package, and then downstream changes to your managed package can break their custom functionality, leading to angry phone calls and support nightmares. Because of this, we had to be extremely judicious with our update pushing, which slowed down development progress substantially. Until very recently with the advent of Salesforce DX, local development was extremely difficult as well - we essentially had to provision many sandbox orgs for our developers, and the always-running nature of those orgs, combined with the limited number of allowed sandbox refreshes, led to lots of problems with unwanted data artifacts hanging around. This made bugs quite hard to reproduce in some cases.
Since Salesforce has evolved as a platform for roughly 20 years, there's a lot to learn. Salesforce's whole ecosystem at this point probably has a similar complexity to AWS (as a whole). As such, if you ever want to do really advanced stuff with Salesforce, I cannot understate how important it is to bring someone on board that has lots of tribal knowledge of the platform before trying to implement it. You're probably fine without such a person if your need is for a simple internal sales CRM, but if you're trying to go beyond that niche, a good Salesforce admin, developer, or architect is worth their weight in gold. There's a reason the big consulting companies make tons of money selling Salesforce implementations - it's hard to do it right the first time, and an improperly managed implementation can spiral out of control really quickly. Fortunately, Salesforce's docs have gotten way better in recent years with the advent of Trailhead, and they've made strides to improve the developer experience as well.
There's one thing that I don't get about Salesforce. They have all the data in world about how their users, developers and admins behave and yet still they don't do much with it.
They should be able to move their entire stack implementation from Oracle DB and x86 to cheap as chips ARM servers, yet they jack up prices for their HDD based systems every year.
They should be able to create this intelligent compiler-linter that should hint at 50% of compile errors, yet they focus on devout "citizen developer" tools that fail miserably at any non-trivial task, create mountains of technical debt, yet get sold to largest companies in the world as cure-all...
And finally, they really shouldn't move hundreds of their New Zealand users from USA datacenter to UK one, just because their account was opened there 10 years ago...
Moving away from Oracle DB is a herculean effort given the heart of Salesforce is still a lot of PL/SQL code :)
To be truly scalable in the modern sense, they should move to a reactive architecture - which means they would have to completely rearchitect the platform with a non-blocking backend. Unfortunately, there aren't many options for them as JDBC can't do non-blocking IO.
Using the Lightning Web Components without the Salesforce back-end is a compelling idea. The design system is well tuned for standard business requirements (rich data-tables, modals, forms, etc.). If there's a good story around using those UI components without having to use the Salesforce back-end this could have value. The Salesforce back-end is a scary entity-attribute-value system coupled to an Oracle database on top of a layer-cake of legacy multi-tenant architecture constraints and years of Java/C code.
How long has this been around? I had to recently build a React app for Salesforce and I had to set it up as something called a Lightning Container Component, which was pretty much a glorified iframe.
I may be entirely misunderstanding what the point of this is, but wouldn't it be better if they just made their API unhorrible and let people use their own components?
It looks like it is a set of components and helpers for building components of your own.
The good thing about Web Components is that they are reusable across frameworks. You don't need jQuery-picker, react-datepicker, and vue-datepicker just <my-datepicker /> and its reusable anywhere.
I work in an org that is looking to provide a lot of the same experiences both within salesforce and outside of it, and I'm looking at this make sharing those components easier. Imagine if you have a calculator and it could be used by both your client relations team (working in salesforce) and on your retail-facing web site.
right now we write two UIs and hook them up the same service. now maybe we get to write one UI.
Salesforce is brilliant at marketing, I would take this PR announcement with a grain of salt.
Lightning was already based on open source software - their Aura Framework. As of March 2019 they decided that they were going to continue to maintain it, but were ceasing to make it open source.
> Lightning web components are custom elements built using HTML and modern JavaScript.
> The Lightning Web Components UI framework uses core Web Components standards and provides only what’s necessary to perform well in browsers. Because it’s built on code that runs natively in browsers, the framework is lightweight and delivers exceptional performance. Most of the code you write is standard JavaScript and HTML.
> Build apps anywhere, any way. You can build an app with your favorite tools, like Webpack, TypeScript, and Babel, and run it on Heroku, Google, or anywhere else. You can also package an app to create a desktop experience in Electron.
Which I think is equivalent to just saying this:
> Lightning Web Components is a lightweight, cross platform, and framework-independent web components library that builds on the native Web Components standards to add some convenient functionality.
Do you have a CRM that you prefer? Back in the day when SFDC took off like wildfire, the choices were essentially Oracle and Siebel (who came from Oracle, just like Benioff did later).
Unlike the top-down Enterprise sales approaches of Oracle and Siebel, there was a fair amount of bottom-up marketing/sales effort targeting individual sales people who could put $20/month on their credit card and expense it (regardless of what their retcon'd history book tells it).
I guess that these days we have NetSuite (Oracle, again) and HubSpot. Are those any better?
I'm not sure; I mean we pretty much had our own homegrown CRM which worked pretty good and we had a ton of internal knowledge about it.
Management was promised magic.. big effort to move everything to Salesforce, and now the entire thing is a shit show. It was supposed to also provide creating what we needed faster, except deadlines are 1.5 years past the time it took to build our in house solutions to begin with!
I don't know what other ppl should do, but I really wish we kept all this internal.
