With our Integration Fields feature you can connect Prismic to any third-party data source via an API and, whilst it is most popular with our eCommerce users to manage product catalogs, its uses are effectively limitless.

Integration Fields: enrich your products with Prismic

When you build anything, the ideal situation is to be able to choose the tools, services, and technologies that are most suited to each individual requirement. In fact, it’s this concept that leads many website developers to go ‘headless’ with their CMS.

By going headless, not only do you enter a landscape packed full of powerful CMS with great features, usability, and capabilities, but you also adopt an approach that allows you to choose best-in-class tools and services for each of your needs.

Now, this sounds great on paper, but it’s meaningless if the CMS you choose doesn’t make it easy to connect each of these services and that was one of the main reasons why we created Integration Fields.

If this is the first that you’ve heard about the feature, or indeed, about Prismic itself, then it is probably best to take a closer look at exactly how the feature works, but the ability to connect directly to legacy systems will not only allow you to integrate date and product catalogs, but also ease transition from your existing CMS to Prismic.

We’ve already mentioned that this feature is particularly popular with our eCommerce users and the reasons behind this are fairly obvious. By connecting to a third-party data source, say Shopify, BigCommerce, PrestaShop, or whichever eCommerce platform that they prefer, they’re able to continue to manage their product catalog using a service that was designed for that purpose and then import and enrich that data directly on their website.

In its most basic form, this provides our users with the easiest way to list products and prices and ensure that they are always correct and up to date, but the feature can also be used to highlight particular products and provide a more interactive user experience for visitors to their website.

The ability to easily enrich a product catalog has become increasingly important over the past few years and our webinar with Arkade looked at how crucial good content is to creating compelling products and an engaging visitor experience that helps increase brand identity and, most importantly, sales.

We’ve even made Integration Fields even more powerful by opening an API that allows you to push your updates without having to wait for our next refresh. Your updated content will be instantly available, meaning that, say you are running an eCommerce website, your price updates will be reflected on your website as soon as they are updated on your eCommerce CMS.

From a content management standpoint, this makes everything incredibly simple. You can manage your products safe in the knowledge that changes to your pricing will be updated on your website will be as soon as you have updated your prices in your eCommerce CMS. One change reflected everywhere.

We want to make content management as simple, easy, and intuitive as possible and ensuring that our users only have to do something once is a key of part of that.

The fact is, almost every website can benefit from incorporating third-party data or content. We even used a recent live coding session to show you how Integration Fields could be used to import content from Twitter, Facebook, or any other social media platform.

Integration Fields is just one example of a feature that we feel offers Prismic users a game-changing content management experience. So, if you’re currently experiencing the pain of managing multiple systems and updating content in more than one location, we suggest that you visit our website and book yourself a custom demo.

We used our October meet-up as a chance to announce our new version of Slice Machine. With the added power of the Slice Builder and Shared Slices, this new version makes building websites with components even easier and offers a significantly improved developer experience.

Slice Machine updates: Slice Builder, Shared Slices, and a Slice Contest

Since its launch back in May, we have been overwhelmed by the level of support and excitement that Slice Machine has received from the community. This support has not only helped us to get the project off the ground, but also helped us to identify areas where Slice Machine can be improved.

And that is why we were so excited to announce the new updates to Slice Machine. These improvements have been the result of countless feedback sessions, contributions from users, and meetings with technology partners and we are sure that they will deliver an improved developer experience and a stronger product.

We used our October meet-up as the chance to announce and demo these improvements and updates. The event was attended by more than 200 people and, just like with the product itself, we're so happy to see the success of these events and role that they can play in helping us to develop closer ties with our community and in allowing users to give us feedback and ask questions.

This was our third product meet-up and we'll be hosting them on a monthly basis (usually on the last Wednesday of every month depending on holidays) and you can already sign up for the next event.

The major update is the addition of the Slice Builder. This local component development environment gives you all the tools that you need to generate data models and mock content. You can then use Storybook to preview how real data will interact with your carefully crafted component libraries.

Slice Machine’s main goal is to improve the way that developers are able to build websites and to create a tool that allows them to think of websites as individual sections and to create and re-use dynamic components that will be the fundamental building blocks of their website. Slice Builder is an important step towards delivering that promise as it will allow you to test your Slices before pushing them to a live production environment.

In addition to Slice Builder, we also used the meet-up to take a closer look at Shared Slices. Shared Slices will allow you to make changes to a single slice and have it updated in any other locations in which it is used. Once again, this simply makes slices more powerful and makes it even easier to adopt a component-based approach to website development.

But, I know that the events are far more interesting than our articles, so here's the full recording of the session so that you can watch the demo and see all of the details for yourself.

We’ve already touched on how great the response from the community has been and we saw this update as the perfect opportunity to reward some of those contributions.

With that in mind, we’re launching a competition where we are inviting users to submit Slice Machine libraries (comprising of a minimum of 5 Slices) and offering up some great prizes in return.

Each participant will receive a Prismic swag bag and, as if that isn’t enough, the two selected winners will also have their choice between a PS5 and an SM7B microphone.

You can read this article for the full details about the contest and for helpful links to starters for both Next and Nuxt.

The winners will be announced at our next meet-up on the 24th of November. If you attended our last meet-up we would be very interested in getting your feedback so that we can continue to improve our events.

Speaking of prizes and rewards, we know that virtual events aren't quite as fun as the real thing and that an in-person meet-up would usually involve food and drinks. So to make our last meet-up feel a bit more like the old days we sent every attendee an UberEats voucher so that they could order something for themselves ahead of the start.

It was great to see the variety of meals that people ordered and shared on Twitter using #PrismicPicnic. So, I'll wrap this up by giving you a look at what people used their voucher on - maybe it will give you some inspiration for your next meal.

Now, we don't want you signing up for our next event JUST because you might get a voucher, but we definitely won't be ruling out doing something similar again in the future.

Slice Machine update: Slice Builder and a Slice Contest

With a headless approach becoming increasingly popular, what are the benefits - even for large enterprise websites - for switching away from a monolithic CMS and turning to microservices.

Webinar with Tim Benniks: From a monolithic CMS to microservices

There's no denying it. Microservices are becoming increasingly popular. This switch has resulted in the boom in SaaS companies and, within web development, has driven the increasing number of CMS options and movements like Jamstack.

As the first 'headless' CMS option on the market, there can be no denying that Prismic has played its own part within these trends, but there is still a large percentage of companies out there that think that their only CMS options are the monolithic providers that dominated the 2000s.

Smaller websites and companies have been faster to adopt and adapt and whilst we work with many large companies around the world (you can check our website for all of the necessary references and eye-catching logos), there is still the occasional pushback from enterprise clients looking for a familiar face in the CMS scenery.

So, with that in mind: why should you switch from a monolithic CMS to a more modern approach with microservices? We have our own opinion, but we thought it would be good to turn to an expert an invited Tim Benniks, the director of web development at Valtech to join us for a webinar. 

We're always quick to point out that every CMS has its advantages and that different projects and use cases will have their own unique requirements that might make one CMS or another more suitable. With that being said, there are real, tangible reasons behind the growth in popularity of non-monolithic CMS providers. In fact, no point drives this home more than the fact that many of the traditional CMS monoliths including WordPress, the Goliath of the CMS world, have started to release offerings that more closely resemble a microservice approach.

Monolithic CMSs are what most web developers and content creators will have grown up with. If you've made it this far without ever having used WordPress you have had a truly unique experience and a monolithic CMS will offer all of the benefits of rich ecosystems (sometimes too rich...we're looking at you WordPress and your ever-expanding universe of plugins), a range of features, and the added simplicity of a single deployment.

All of that sounds great. Right? So why would you ever want to complicate your life and have to deal with multiple services when you can just use one?

With a monolithic CMS you are locked into your provider. Want to switch your stack later on? You might not be able to. Need to scale your website as you grow? That might be tricky. Oh and that rich ecosystem of plugins may result in security concerns and the need to constantly update and maintain your CMS.

But...but...at least it should be cheaper. Right? Paying for a single CMS must be less expensive than paying for several services. Not so fast.

Microservices offer the benefits of reduced costs, the ability to choose the best-in-class solution for each of your needs, high performance, and scalability.

You'll be able to choose the microservices that are most suited to your project even as your website scales, your business evolves, and your needs change.

At Prismic, we regularly see our users update and adapt their stacks as their needs and business change - and never has that been more important than in the current climate.

So, with that introduction in place, let's let the expert speak.

You can watch the full recording of our webinar with Tim Benniks. If you are interested in attending future webinars you can sign up for our Prismic Events mailing list for all of our news and updates regarding meet-ups, webinars, talks, and conferences.

If you'd like to find out more about Prismic and what we offer, you can start using the product today and reach out to us to schedule a demo.

Without further ado, here's Tim Benniks and Adrien from Prismic to take a closer look at this topic.

Webinar with Tim Benniks: from a monolithic CMS to microservices

We know that some of you have encountered difficulties with our plugins for Gatsby, so we thought that we should clear things up a bit.

Gatsby-Prismic plugins: what's going on?

N.b. The recommendations in this article are only relevant for Prismic users that are still using the gatsby-source-prismic-graphql plugin. This is no longer our recommended solution for projects with Prismic and Gatsby.

If you are starting a new project or looking to switch to the correct plugin, then we recommend that you take a look at our new documentation and read this article on migrating to the new plugin.

That being said, much of this article does explain our long-term goals for using Prismic with Gatsby and our commitment to delivering the best possible developer experience for our users.

Gatsby is one of the most popular frameworks among Prismic users. Prismic's flexibility allows users to build the stack that they prefer without foregoing any of the benefits of any of the technologies involved. When paired with Gatsby, Prismic websites remain lightning-fast but also provides features and benefits that make managing a website and content much easier.

In developing Prismic, we have focused heavily on ensuring that all of our users have access to our key features regardless of their Prismic plan or the stack that they build. That commitment has been a large part of our success and it is the reason why many developers see us as the best option for small projects and why enterprise clients trust us with large websites.

That being said, if you’ve decided to read this article then there is a good chance that you may have encountered some of the issues regarding the Gatsby-Prismic plugins or, in the very least, you’re aware of some of the issues that people have been encountering. That commitment to delivering every feature with every stack has run into some problems when it comes to delivering multi-session previews in Gatsby.

Not been affected? Well, you may still find this article will provide an interesting look at the difficulties of managing plugins, third-party integrations, and product decisions.

The fact is, it’s rare for us to have to comment on issues with plugins. One of the major benefits of Prismic over traditional CMSs like WordPress is that our product doesn’t involve managing a world of plugins. For the vast majority of users, they can access all of our features right out of the box and never look back.

But before we get on to that bit of the story, it is probably best to start at the root of the problem: the Prismic Previews feature.

Previews are one of our most popular features. Whilst almost every CMS will offer some sort of preview feature, ours offers functionalities that most don’t match.

With Prismic Previews, you can instantly generate a preview of the content that you are working on, see exactly what it will look like as a finished product, and use a link to share that version with anyone else — including no Prismic users.

These shareable links even update to reflect any changes that you may have made to your content after sharing that link, so you don’t have to worry about the fact that you sent a link and then made a small change before the other person was able to see it.

What’s more, these are multi-session previews. Meaning that you, and anyone else with access to your Prismic account, can be generating simultaneous previews for different pieces of content and it will cause you no issues.

Prismic Previews are one of the biggest game-changers for content creators when it comes to managing their workflow.

We obviously use Prismic for our website and all of the articles that we publish and I can’t tell you the number of times I will generate a preview to check what my content will look like or to share it with a colleague before I publish. It helps me to shape my content, proof-read, and ensure that it is consistent with the overall style and look of the rest of our work.

Now, I’m sure that you can see where the issue is coming. How do we generate multi-session previews for statically generated content?

Delivering multi-session previews with Gatsby

We know that a lot of our users choose Gatsby. We’re huge fans of the framework and we can understand why it is so popular amongst our users and within our community.

So the challenge for us was to make sure that we could offer all of Prismic’s core features and functionalities to Gatsby users and just over a year ago we thought we had done it.

The Gatsby plugin was developed by Birkir Gudjonssen from Ueno and he, along with our team, was able to find a solution that would allow multi-session previews in Gatsby without making any significant changes to your code.

The details of how he did that are actually very interesting and worth reading about, so I would encourage you to read this article from last year, but, as you will already know, we’ve encountered some difficulties with this plugin.

It is important that we say that we are incredibly grateful of the work that Birkir put in and the plugin was a great solution at the time, so the problems that we have encountered are in no way a reflection of his work.

In fact, we even saw this plugin as a sign of a thriving ecosystem that was growing around Prismic. We work very hard on involving our community in our decision-making and roadmap and it is always very pleasing to see members fo the community working on solutions, workarounds, and improvements that they can share with other Prismic users.

One of the biggest issues has been something that will be very familiar to anyone who has ever worked on third-party integrations or plugins.

The GraphQL plugin relied on an internal mechanism from the Gatsby framework and not on a stable API. This means that there is a risk that it may break whenever Gatsby makes an update or a change to their framework.

This is a pretty big issue and it has caused problems throughout the lifetime of the plugin.

This problem also leads us on to the one major downfall of having community-created plugins and solutions. Whilst we were involved in Birkir’s work, we were only contributors. So whenever an update to the plugin was required we were in exactly the same situation as all of our other users.

We know that this has caused significant frustration as some users didn’t realize this and thought that we were instead ignoring the issues with the plugin. This wasn’t the case.

When these issues started to grow we knew that we would need to find a different solution, particularly as we can’t expect Birkir, or any other member of our community for that matter, to maintain a plugin in the way that we will often need to.

So, we decided to reach out to Gatsby themselves and see what solutions we could find and it was at this point that we saw a second major problem.

A few months ago Gatsby launched Gatsby Cloud. It’s a great move for them, but has brought about a shift in their approach that means that they discouraged us from using a GraphQL plugin that wouldn’t support all of the new Gatsby Cloud features — an example of this being the fact that incremental builds will not work with the GraphQL plugin.

As you can imagine, these meant that we needed to make a major rethink in how we would approach this problem. Once again, this isn’t to shift any responsibility away from ourselves. We think that Gatsby Cloud will be really useful for a lot of our users and this is simply one of the many challenges that come with working in a landscape that has so many different technologies at companies operating within it.

We know that some users have read our documentation or watched our videos and felt that we suggested that they use a plugin and a feature that didn’t work properly. We can only apologize to anyone who has encountered difficulties that they weren’t expecting.

For the time being, and we must stress that this is not our long-term solution, we are going to adopt a more standard approach to previews in Gatsby. We are opting for functionality over perfection and are picking a solution that works with Gatsby's incremental builds and will ensure that Prismic and Gatsby users do get a reliable preview feature, even if it isn't as powerful as the one available to other Prismic users.

That’s why we are now suggesting that our users opt for a different plugin for all new projects. This plugin is once again community-created, but it doesn’t rely on GraphQL, is future-proofed for Gatsby Cloud, and we are very heavily involved in maintaining it.

We’ve already made a fork to the Gatsby-source plugin, so it should be ready to use and more usable than the previous version, but we will continue to improve and maintain it over the coming months.

You will still be able to preview your content, but the preview feature will not be able to play such a game-changing role in your workflow and content management.

What does the future hold for Prismic Previews in Gatsby?

This entire process has been a big learning experience for us. Any reader that has ever been involved in managing product or making product decisions will be able to relate to the fact that you sometimes have to choose between what you think is the best possible solution and what you feel is the best immediate solution.

For a long time, we have fought hard to bring the best possible solution to Gatsby users. We have no doubt that multi-session previews are invaluable to any user and any product and we would want every Prismic user to be able to take advantage of this feature.

But we also need a product that is reliable and that meets the expectations of our users. Gatsby has its own previews feature. It doesn’t allow for multi-session previews, but it works and is stable and that is most important.

Over the past few months, we have worked closely with the Gatsby team and, although we know that they are very impressed with our multi-session previews, it may be best for our users to not expect that this will work in Gatsby for the time being.

Anyone that has been following our updates will know that we are working at hard and developing better partnership with other technologies and companies and Gatsby is part of this.

We don’t want to abandon the idea that multi-session previews will be available to all of our users and we will continue to work hard on finding the best possible solution that will provide this.

So, for now, we hope that this article will answer many of the questions that have been asked in recent times and help you to choose the right Prismic-Gatsby plugin for your upcoming projects.

As for what are solution will be in the long-term? Stay tuned and we will update you shortly.

Gatsby-Prismic plugins: what’s going on?

With development environments, you can test new features, try new designs, introduce new custom types, or prepare any updates or changes that you want to make to your website without any risk.

Development Environments: the feature that allows to safely to test and iterate within Prismic without jeopardizing your production environment

Few things are more important for your website development and maintenance than knowing that you can safely iterate and test new features without putting your live website at risk. But, fear no more, with Prismic’s new development environments feature you can easily clone your production environment and work on new iterations and designs in a separate and safe development environment.

That means less stress for your developers. Less stress for your designers. And a more enjoyable user experience for content creators who won’t have to use new features or designs before they have been thoroughly tested.

You can create as many development environments as you need and easily update and sync them whenever you want.

That’s a good question, but one that is easy to answer.

This feature is especially useful whenever you want to test a new Prismic feature, introduce a new custom type (aka add new Slices), rework the design of a page, or just make general improvements or updates to your website.

Anytime you want to make a change to your website you can ensure that it will work and won’t cause any unexpected changes elsewhere.

We’ve all been in situations where we’ve tried a new feature or tweaked a design only to find that it’s had a knock-on effect on other parts of our website. At best, this might be a small fix that your design team can handle in a few minutes. At worst, it can take your entire website down.

At Prismic, we arm you with a number of features that simplify your production planning and scheduling.

You may already be familiar with our releases feature, which allows Prismic users to schedule exactly when content will go live — including simultaneously publishing large-scale changes to your website.

Development environments will help to make this process even smoother. Allowing you to first test new features updates, before then using releases to schedule exactly when these changes will be reflected on your website.

The new environment is a clone of your production environment. It will copy all of the following aspects of your main repository:

That means that you get a complete copy of your production repository and any iterations or change that you make will take into account all of the features and settings that you have on your live website.

In order to avoid triggering anything on your production environment, it will not copy over any webhooks that you may have configured.

Once the feature is enabled, you will be able to clone your production environment directly from your Prismic toolbar.

All you will need to do is head to the left sidebar of your repo and select the ‘environments’ section.

From there, you can select the environment that you wish to clone, type the name of your new environment.

It will create a new unique URL and API Endpoint for the new environment and you’re up and running.

You can now easily access either environment by clicking on a link to open the environment in a new tab, or by switching between the two by using the toolbar on the left-hand side.

How do I push things from the staging environment to my production environment?

You can resync your environments at any time — ensuring that your staging environment will have all of the latest content from your live website and allowing you to update your production environment once you are happy with any changes that you have made in your safe space.

Be careful though, any changes made in dev will be erased.

Well, not quite a million dollars, but it isn’t one of our free features.

Environments are only available on Platinum Plans and the number of environments that you can have is dependent on the exact plan that you are on.

Want to find out more? Take a look at our pricing and plans or reach out to our team for more details.

Development environments: a sandbox where you can test, try, and iterate safely

Emma Wedekind took the time to stop by the Prismic Studio to speak about her journey to programming and the imposter syndrome that will be familiar to a lot of developers.

Emma Wedekind's journey to Programming: from Java to React

Emma is a Software Engineer based out of Karlsruhe, Germany, currently leading a Design System at LogMeIn.  She was born and raised in Upstate New York. Emma graduated from Siena College in Albany with a B.S. in Computer Science and moved to Austin, Texas, for three years where she worked as an engineer at IBM on Quantum Computing.

She enjoys all things Front-end & Design. She is heavily involved in a number of projects, including Coding Coach in, as a Frontend Masters instructor, Egghead.io instructor, a teacher at Lynda.com, and as a co-host of the Ladybug podcast with Kelly Vaughn and Ali Spittel.

We talked to Emma about her path to becoming a Front-end developer and covered everything from struggling with Java in Computer Science class to learning HTML, CSS, and JavaScript in just 3 weeks. The conversation also covered a topic that will be familiar to many developers in our audience - imposter syndrome and feeling underprepared at the start of your career. 

We had Emma Bostian in our Paris office in December. Interviewed in Prismic's Studio by Sadek Drobi

Two months before I started my internship they said 'we're gonna switch you to front-end'. I was like 'HTML is easy, that's fine, I'll be great'.  So I showed up to work and I was horrible at my job. I quickly realized that front-end development is a lot more than just writing HTML and CSS.

So we're here again at Prismic Studio. Today we're here with Emma. I want to remind you that we're doing these videos about different subjects, about web technology, web programming, CSS, Design Systems. All these kinds of topics, we get a lot of interesting people. So make sure you check out the videos and subscribe to the channel for new ones. So, Emma, thank you for coming. It's great to have you here. First I would like to maybe start with introducing who you are, how did you start with programming, all that journey.

 Sure. Yeah, so, my name is Emma Wedekind, I am a software engineer at LogMeIn in Germany. So, I am from Upstate New York originally, born and raised there. And then my journey into programming is interesting because I never wanted to get into programming. My dad is an architect at IBM, so he was very much into back-end programming. My mom is a senior designer at IBM, and so I kind of grew up in the tech ecosphere. I'm a third-generation IBM-er, so it's kind of strange to think about that. But yeah, as a result, I never wanted to get into programming. Growing up, when your parents say 'oh, you should do this', you're like 'I am definitely not gonna do that.' It's one of those situations.  I was actually a biology major in college in Albany, New York. I realized I was really terrible at it. So, I switched to actuarial science, which is a lot of statistics, and I took an Intro to Programming course or Intro to Computer Science,  I just remember learning about binary and hexadecimal and octal and I was like this is really cool.  So I ended up switching my major over to computer science.  I graduated in 2015 and I moved down to Austin, Texas to work at IBM. I was there for I think three years. I got to work on some really cool projects like I got to work on quantum computing, which is the neatest project ever. It's the one I talk about the most because it's possibly the coolest, but I did a lot of other things while I was there.

Wow, I don't know now which topic to talk about, you just spread so many interesting topics. So your father is a software architect?

Yes. He is, yeah. He's still at IBM. It makes dinner conversations interesting because he keeps trying to pull me back over into the back-end, and I'm just not about it. Don't want to go back there, I like front-end.

During my internship, my dad's previous manager was visiting from Texas and she just came to see me and said 'would you wanna move to Texas?' I was like 'no, but let's do it'. So I moved down to Texas, I was gonna be hired as a back-end developer.

But now even front is becoming front-end and back-end, you know, talking about the 'back-end of the front-end', 'front-end of the back-end'. It all mashes together. You'll end up there.

So you started working at IBM, did you work as a front-end developer there?

During my senior year of college, I did an internship where I automated the installation of a WebSphere Application Server on z/OS with Python. It's a lot. I know. I had to memorize that for my LinkedIn profile, I don't know what any of it means. So, I did an internship for six months. I tried to use WebSphere. I still couldn't tell you what it does. During my internship, my dad's previous manager was visiting from Texas and she just came to see me and said 'would you wanna move to Texas?' And I was like 'no, but let's do it'. So I moved down to Texas, I was gonna be hired as a back-end developer 'cause I did Java all throughout college and assembly language and database, and so I was like 'yeah, back-end, sounds great'. Then two months before I started they said 'we're gonna switch you to front-end'. I was like 'HTML is easy, that's fine, I'll be great'.  So I showed up to work and I was horrible at my job. I quickly realized that front-end development is a lot more than just writing HTML and CSS.

People don't recognize the fact that there is math in almost everything we do, including design, which is really hard. They see front-end and they think about it 'oh, there's nothing mathematical or super technical, as much as the back-end' and that's a common mistake.

 I mean, there's this kind of always discussion about whether back-end is harder or front-end is harder. I'm a back-end person. But I know it's so complex to do front-end, the complexity is way higher I think.

Yeah, I feel like there's a lot more tooling. They're different. I don't like to compare and say one is harder than the other because they're so much more different.

Front-end has a lot of unpredictable things that could happen. You know, browsers, and network, and all these kinds of things. I mean, back-end has also a lot these kinds of things, but less unpredictability I feel. Like CSS, come on, it's so complex.

I love CSS, but I know most people don't. It's complex because there's a lot rooted in math, and people don't understand. For instance, specificity is a topic that you should understand if you're gonna write styling. But people don't recognize the fact that there is math in almost everything we do, including design, which is really hard. They just take it for granted and they see front-end and they think about it 'oh, there's nothing mathematical or super technical, as much as the back-end' and that's a common mistake.

That's another topic that we should absolutely talk about. This would last forever, you know. So what was the first programming language you started with? Java?

Java yes! Well, technically Alice, but that was a drag and drop program, so yeah, I used Java.

I hate Java, I hate it. Probably because I was really bad at it. I think your teachers have a big impact on your success, and I think that the teaching style that I was provided with didn't match with my learning style necessarily, for some of my teachers. So my first Intro to Programming class was with Java, and it was with a professor who was brilliant, but I did not click with his teaching style, so I struggled a lot in Java.

I will try to be bolder than that, I guess it's Java. I mean I've done a lot of Java, and I know maybe people will hate me for saying that, but Java is evolving a lot now. It was this language that was not evolving at all. It was like it didn't have functions, it didn't have anything and you had to define everything in classes, you say the variable name, the variable type equals the variable new, and it's so verbose.

It's really verbose, and you have to understand object-oriented programming really well, which I did not. Trying to program it in Eclipse, which is a massively confusing IDE, was just horrifying for me. I think our senior project was coding Ticket to Ride. Which, I still can't play that game. Great game, can't play it, I have a lot of negative feelings about that.

 I fully understand. So now, you started with Java, and then you went into writing HTML?

No, I did assembly language, so I programmed in MIPS. We did a lot of assembly programming. I did some database with MySQL, and then.

Why Java then? Why not starting with writing assembly directly?

That's just the language we did everything with. I didn't go to a technical school, I went to a liberal arts school. So their computer science program was pretty small. I think Java was just the language that they chose. They didn't teach Python at all, or they didn't teach C or anything like that. It was just Java. So that was used throughout my algorithms courses, my programming courses, my data structures courses. Then when I found out I was gonna be working as a front-end developer I took Front-end Development (or Web Development) and that was not as helpful as I had hoped it would have been. We learned a week of HTML, a week of CSS, a week of JavaScript. Then we learned Bootstrap. They didn't touch anything in regards to JavaScript frameworks. I had no idea what a JavaScript framework was until I showed up to work on the first day and they were like 'we're using Dojo', and I'm like 'what is that? I have no idea' so it was really hard.

I think graduating from a computer science degree, I had a big ego, and I was like 'I know everything, I deserve this job'. Then I showed up and it was a reality check. Now I'm fighting imposter syndrome

That touches also the topic of: when you join a new job and you think you know what programming is, then people start talking about a series of names of different technologies: 'Oh, we use this with that and that' and you understand that you know none of that.

It destroys your ego pretty quickly. I think graduating from a computer science degree, I had a big ego, and I was like 'I know everything, I deserve this job'. Then I showed up and it was a reality check. Now I'm fighting imposter syndrome, I think we all are to a certain extent. Yeah, I would say as a junior developer I had a big ego, and it was quickly beaten down.

For people that didn't have that ego, it's kind of overwhelming as well when you get into it. There's so much to learn and you get scared, right? Because you see everyone understanding that except you. Is it you, what is the problem exactly? Why are you not on the same page as them?

Yeah, absolutely, and I think also being the only female front-end developer was really hard because I thought it was just me and I just wasn't cut out, and not having someone similar to you on your team that you can go to for support or for help was really difficult.

Let's dig deeper into these topics in the next video.

Emma Wedekind's journey to programming: from Java to React

We've partnered with imgix to provide an Image Optimization feature that will deliver next-gen images, images that will be optimized for your end-user, an improved interface, and much more.

New Prismic Image Optimization with imgix

We've partnered with Imgix to provide Prismic users with image optimization, next-gen image support, and an improved interface that will give them greater control when cropping and editing their images.

To keep it simple, we're a technology-agnostic headless CMS. Is that simple?

Well, to keep it short at least, when using Prismic, developers are able to pair their CMS with whichever frameworks and technologies that they prefer. We also try to develop features that maximize the benefits of their other technology choices. A great example of this is the fact that we are a component CMS - meaning that you can use the same component-based approach on your frontend and your backend.

But we know that a CMS doesn't stop with developers and so, even though we see them as our focus, we've also developed an intuitive user experience for content creators. That component-based approach also means that our Slices feature allows content creators (including the most technologically challenged out there) to independently create and edit pages - giving them more autonomy and leaving developers with more time to focus on their actual product.

We're working hard at providing the best possible developer and editor experience - and that's why offering image optimization and an improved user interface for manging images was so important.

You've heard it all before, time for us to puff out our chests and tell you how great we are.

But, no, when we work on new features, we work on things for our users, not just for us - and this one is no different (I know, we sound amazing. Don't we?).

So, we're excited to announce our partnership with imgix (a service that transforms images on demand and in real-time via a simple URL API) to deliver our new Image Optimization feature, but we're even more excited to see what it will do for you.

Image Optimization is an example of a feature that will improve the experience for all Prismic users. That isn't to downplay the importance of any of the other new features that we roll out, but it is great to share news about a feature and be able to say that EVERYONE should pay attention.

It will make a world of difference. Right off the bat, the improved user interface will make it easier to select, crop, and adjust images. This will help you to save time whenever you are creating new content and allow you to be sure that images look just the way you want them to on your page.

And to make that even better, images will be optimized based on how your end-users are visiting your page. If you've got someone using Chrome on a mobile they will get a Webp that is optimized for their browser, even though they've uploaded a heavy JPG file.

It's sometimes easy to overlook the experience of your end users when you are producing content, but this feature will ensure that they have the best possible experience whenever they visit your website or app. 

You've probably got this figured out from the title, but in case you are interested in a better explanation of the exact details of what has changed, here are the basics (if you aren't go ahead and skip to the next paragraph, I won't judge you). 

We've replaced ImageMagick with imgix, meaning that, from now on, instead of images being forwarded through our bucket and custom CDN, we're now forwarding image links through imgix for transformations. So the transformation requested is computed on the fly on the first request and then cached by the provider.

OK, we got through that, now I can tell you about some more of the benefits.

You first concern is probably: what will I have to do to get this working?

Well, we've got some good news on that front. This will work right out of the box without you having to do anything. 

With this feature, we will now support next-gen images. So formats like WebP will now be displayed whenever the end users browser supports them. 

This will even give you the possibility of using the imgix API to generate your own transformations. You can refer to the imgix documentation to see all the transformations you have available.

And improved image compression also means that your CDN consumption will go down - our own tests have shown that images will be roughly 50% smaller. 

We know that this is more of a win for us, but it is still good news for those of you out there who are consuming bandwidth like it is going out of style. 

The real reason to be excited about this feature is the impact that it will have on your SEO. End user image optimization and compressed images means faster loading times for your websites, and that means better SEO.

No matter where SEO falls in your marketing strategy you can't undersell its importance and any improvement is a step in the right direction. 

Our own tests have shown that Image Optimization will improve loading times considerably and users will see their website's time to interactive drop by an average of more than a second.

That isn't to say that you can ignore the other SEO best-practices that you need to follow when it comes to images, but you can get a great overview of these from imgix themselves.    

Update – January 14, 2020: This feature is now available by default in every repository.

Update – August 14, 2019: We've already worked out most of the kinks, but the feature is still in beta testing for the time being. That doesn't mean that you can't start using it today, but you will need to get in touch with us to request to test it. You can do this by just clicking on the chat icon in the bottom right corner and telling us that you would like to beta test the feature. Don't be shy! Let us know if you would like to try it out, but if not, all Prismic users can look forward to Image Optimization in the near future.  

Have you really thought about why you chose the CMS that you use? Did you just choose Wordpress by default? It might be right for you, but for a decision as important as that you should consider alternatives. Here are a few reasons why Prismic might be the right choice for your project.

Prismic vs. Wordpress - a Wordpress Alternative

A lot of articles like this will start with the company trashing their competitors and proclaiming themselves to be the one true solution. That isn’t how we work.

We know that there are a lot of great options out there when you are choosing your CMS. We know that there is a reason why roughly 30% of the internet runs on Wordpress. But we also know that we are really good at what we do.

We wouldn't be here without Wordpress. They have very much lead the way in the development of the CMS landscape. Their product has helped millions of people to create websites and we have tremendous respect for what they've done. 

Their product is adaptable and reliable and the ecosystem that surrounds it has lead to the development of a world of plugins that help people to get more out of Wordpress - but that doesn't mean that there isn't space for new solutions that have learned from what they have done. 

Wordpress changed the landscape, but one of the downsides to getting there first is that you get pulled in every direction. Their extensive ecosystem is great and all of the plugins make it extremely adaptable and versatile, but it also makes it slow and unwieldy to manage. 

That is where we saw our niche - providing a CMS that allowed developers to use whatever technology they prefer, right out of the box, without having to manage a host of plugins. With Prismic you get to choose your technology, framework, and language. You have access to a dedicated support team. You can count on high SLA's, a secure platform, and a writing room that has been designed with creators and marketers in mind. 

Wordpress might be right for your needs. A non-headless CMS might be easier for you, but all we’ll ever tell you to do is to just ask yourself one question:

Edward Hewitt

Integration Fields: enrich your products with Prismic

Slice Machine update: Slice Builder and a Slice Contest

Webinar with Tim Benniks: from a monolithic CMS to microservices

Gatsby-Prismic plugins: what’s going on?

Development environments: a sandbox where you can test, try, and iterate safely

Emma Wedekind's journey to programming: from Java to React

Prismic Image Optimization with imgix

Prismic vs. Wordpress

What is Serverless - Episode 5: Building a fast website

3 Things I wish I'd known when starting with React

What is Serverless - Episode 4: DevX and Collaboration

What is Serverless - Episode 3: Deploying applications globally

How Next.js and Gatsby work and how they're different

What is serverless - Episode 2: Scaling your application

How to choose a tech stack for your website - Episode 2:

What is Serverless - Episode 1: Introduction

How to choose a tech stack for your website - Episode 1: Introduction

Choosing Next.js, TypeScript, and StoryBook for your Tech Stack

Our Improved Translation and Localization Feature

Deliver a website with a visual Page Builder for your marketing team