Haha Iām the C# guy and donāt know how to use app studioā¦let alone pivot tables 
5 Likes
If it was faster, I would agree with you 1000%. But itās not. Itās WAAAYYY slower to do the same thing. And once you learn the basics, you quickly realize itās the exact same thing. Each BO Call widget is a method call in code, with the parameters listed out. Itās LITERALLY the same thing. Same with BAQās is a wrapper for SQL. Itās LITERALLY the same thing with a couple of epimagic tools thrown in there.
I hate to be rude (but Iām gonna be a little), but you refuse to learn how to code, and proclaim that you are proud of it, not realizing that you already know how to do 90% of it and if you would just buckle down and learn some syntax and how to do some for loops youād be able to do it. Iām not saying youāre not smart, Iām saying youāre stubborn. So when you say that you know that āToolsā are better/faster, when you donāt even know how to code is like me telling the (insert whatever controversial scientific discipline here) scientist that they are wrong because āI did my researchā aka watched 2 youtube videos.
Widgets/visual coding sets up the first step/framework for you so you can get started faster, but when you need to actually pounds out a large volume of logic, it takes way longer to set up widgets, or snaps or whatever click and drag thing they come up with. The mouse it just inherently slower than typing code with intellisense.
4 Likes
One tool shoe-horned into two use cases isnāt necessarily better than two tools.
Yes, the 20-widget monstrosities as we call them are quite uglyā¦ But this is where you should be writing C# in my opinion.
That said, perhaps the SNAP idea has some meritā¦ In my opinion, 4 or more widgets is 
in a BPM/Function. Does SNAP bring that number to 10 before itās ? To 15? I still much prefer C# to any number of widgets in my environment but I can appreciate the argument here.
In any case, Alisa is spot on here,
No one has any appetite for this at all until we see significant improvements in fixing bugs.
6 Likes
I mean, I am provoking it - itās fine.
Definitely that. It is deliberate stubbornness.
They can be. Not always, of course.
The point is, the overarching fear of anything new is what I am pushing back against. Not you specifically; just overall in this discussion.
I agree the equivalent of a PivotTable (the tool that is better than code) does not exist in Kinetic. But it should, and I want to support the progress toward that goal.
BPM widgets may beā¦ 30% toward that goal. SNAP may beā¦ 40-50%? (Totally guessing of course.) But Iām hoping for the day we are atā¦ 80%?
3 Likes
Given Epicorās recent track record with foisting new things on us that either donāt work at all, or donāt work as well as they used to, I donāt think this is a fair characterization of the conversation.
Thereās a ton of accuracy in that, yes.
So, App Studio replaces two things:
- āDashboardsā made of one or more BAQs
- Customization of a screen - either a dashboard or any ordinary screen like Part Entry.
Dashboards got much harder with App Studio - for anyone and everyone.
But customizations are much easier to me now in App Studio.
I had done some customizations in Classic years ago but basically entirely abandoned the practice. If all I need is for a person to be able to edit a UD field, Iāll make an updatable dashboard instead of customizing the relevant screen.
Also...
This practice works on an a Data Collection license rather than requiring a ādefaultā license to open Part Entry or whatever. So thereās the frugal part of it, too.
Now I have a reason to make apps from scratch, since I can actually get them to do what I want.
So for me, the pain of App Studio is still an improvement over the pain of Classic customizations.
But for most of you here, itās the exact opposite. I am sorry for that difficulty. But I donāt see Kinetic as the abject failure that others do.
4 Likes
Being old, these discussions make me smile. I have seen these arguments before about programming languages. I remember when procedural languages ruled the land: BASIC, Fortran, C with their spaghetti code and GOTO statements everywhere. The assembly language people scoffed at the larger size and longer run times. And then strongly typed and structured coding languages like Pascal and Ada came onto the scene. The procedural people again complained about the bloat and slowness. Functional programming appeared in the late 50s, and everyone ignored them because they were mathematicians and not solving real business problems. Object oriented appeared and the howling of size and speed was deafening. Most recently, scripting languages (Python, Perl, JavaScript, ā¦) and VM languages (C#, Java, etc.) have been eating up the world but they too are bigger and slower then their predecessors. Where we are on this ride is usually where we were in our mid 30s. After that, we tend not to like ānew stuffā, i.e. become stubborn. There are exceptions of course, but as a rule Iāve found it a good heuristic.
The question will always be, is balance. What tool provides the best solution for business problems, now includes maintainability, ease of modeling, and security. Functional programming (F#, Haskell) is making a comeback because it does parallelization well. Rust is adding to the security stack. As the business needs change, so will the tools. If we optimized for only one area, there are clear choices, but if we look at all of the needs of the enterprise, there are trade offs to make.
12 Likes
My beef is C# code is very mature, and widely adopted. It can do everything you need it to do and more. And if you have a problem, itās not proprietary, and thus, probably already has an answer out on the interwebs. I like to be proud that I came into programming Epicor from a mfg base instead of a coding base, because I can google an answer to a code issue. Itās really hard to google an answer for a manufacturing strategy problem.
I guess my problem is more āProprietary means less supportā issue (even if they fix the āitās slowerā issue. Which I doubt will happen). Sure Epicor can make their new shiny thing, but if itās locked down and no one else uses whatever tool they use, because they created it, that means 1. Itās hard to find anyone who knows what to do, and 2. if itās broke, fixing it is 100% on epicor. (And we all know how some of those bug tickets go).
One of the things I believe that they did VERY right in the 10 release was move everything to a well known, well used .net platform. @Bart_Elia was a huge proponent of āNo throwaway knowledgeā. If you learn some C# in Epicor, guess what? You can now use that in other areas too! I didnāt know any C# before I started with Epicor. I learned it because of epicor, but now I have the ability to make some simple console programs that can do stuff that doesnāt have to do with epicor. (I mean they usually do, but they donāt have to) Can you do that with widgets? Everything you learn on these proprietary home grown systems are locked down to that system. (I guess not everything, logic is logic, and you get better with practice, but I hope you get my point.)
7 Likes
We did a demo of CPQ at my old job that was very configurator heavy. Half the demo was this snap stuff, and our COO pretty much nixed the whole idea because of it.
4 Likes
I largely agree with your sentiment, but I feel like it conflates abstraction a with medium a little bit. As we moved away from assembler all the way up to C# we got massive productivity gains because we abstracted away complex details about hardware and such. So if you had someone good at assembler, they could still be more productive in a compiled language, even if what they produced was less optimized.
So how come that isnāt the case moving from written languages to visual ones? If you take a developer and make them work with a visual system, they will be less productive, not more.
The visual medium does not lend itself to productivity, at least all the implementations weāve seen so far.
3 Likes
Not all of us are developers though. Many of you can write a screen of C# code quickly to do what Iād use 3 or 4 widgets too accomplish. If I had to do it all in code itād take me longer than using widgets.
While Iām not opposed to @timshuwyās idea in theory, I do feel there are bigger more impactful things they should do before considering this. With Classic sunsetting in a year they should be focusing on the remaining rough edges of Kinetic UI and improving App Studio. Both would be a larger QOL and ROI for every Epicor customer.
8 Likes
Iām not a developer either, but if you give me a choice of explaining how to make a dish to someone I am going to write them directions in the form of a written recipe not draw them a picture 
We are all a bit off topic now. 
2 Likes
I agree, thereās a tipping point, where some simple things are faster, and that point moves with practice.
What we are all really worried about is what they did with App studio and took ALL of the code out of it. They say they wonātā¦
2 Likes
Laughing, because the same thing occurred to me. The perspective of being old! Typically, these discussions become moot, unless you are in complete control of the app or development environment. A bit more interesting, in this case, because everyone is trying to persuade Tim!
4 Likes
You make a lot of good points here, but I have to disagree with this:
Maybe simple customizations are easier in App Studio, but complex customizations & new apps can be much more difficult if youāre trying to reach across different modules.
5 Likes
I need submit an idea for Youngāns Only Frideas posts. All this rationality and perspective is really distracting!
8 Likes
Like I said, if we optimize for a single thing (developers), you will have a clear winner. If I take a Business Analyst and make them use C#, they wonāt be more productive either. But ERP systems were not created for developers. There are more non-developers using an ERP system then developers, and developers will never get to the bottom of the ERP Usersā Wish List. How does a software company make the software more accessible? PowerAutomate/Logic Apps, MS Access, LabView, and Node-Red are pretty successful visual languages that have made developers more efficient. 
Itās likely not going to be all one or the other. It will be a little of both.
2 Likes
I 100% agree with not removing C# if they ever move on this idea. Taking away viable tools is a nonstarter for me.
Kids these daysā¦ 
1 Like
Thereās a lot in this post, but in a nutshell, I think I agree with every word.
3 Likes
They initially said they were going to do the UI system in angular with nodeJS. Then they didnātā¦ I donāt know either of those, but I do know that they arenāt just epicor specific. So history has us a bit shell shocked I guess.
4 Likes