Are There Any Strong Reasons Not to Use Nuxt.js? 7 Issues that Might Discourage You from Choosing It
It helps you boost your SPAs' SEO, it enables you to generate your apps both on the server-side and statically, it "spoils" you with an opinionated structure and setup... so you cannot help wondering: "Are there any reasons at all not to use Nuxt.js?"
Considering its heavy load of too tempting capabilities (and I've briefly outlined just some of them), you ask yourself:
"Why would I not (always) choose it over regular Vue.js for building my PWAs?"
"Why would I ever bother with a... "Next.js or Nuxt.js" dilemma, for instance?"
In short: what are Nuxt.js's limitations (if any), those that could make you at least doubt for a minute or two before choosing it for your future SSR projects?
Well, we've run our investigation and managed to identify its 7 key weaknesses (for there are, indeed, a few).
Weaknesses that we're about to share with you, so you can give yourself a well-founded answer to your question:
"Why should I use Nuxt.js over Vue CLI for building an SPA?"
1. But What Is Nuxt.js More Exactly? How Does It Work?
Before we go ahead and expose its weaknesses, it would be only fair to define this framework properly, right?
A concise, yet accurate definition would be:
It's a high-level framework that helps you build SPA and universal Vue.js apps more easily.
While a more detailed one would be:
It's a minimalistic Vue-based framework that simplifies the whole process of creating server-side rendered apps. It'll handle all the UI rendering of your app project, abstracting away the client code distribution and complex details of the server.
From routing to asynchronous data, to middleware, it'll handle all the complex pre-coding configuration, so you can focus solely and entirely on... developing a great Vue.js web app.
2. How Can Your Project Benefit from Using Nuxt.js? 5 Strong Benefits
Let's highlight some of the most "irresistible" capabilities of Nuxt.js, those that might have already made you stop and wonder:
"What possibly could determine me not to use Nuxt.js... in all of my future SSR projects?"
it's great for SEO: it solves all the SEO issues that single-page apps are reputed for (client-rendered content, mobile web performance, URL and routing, etc.)
it generates static websites via the "generate" command; moreover, it ships with powerful features, similar to other famous static site generators like... Jekyll, for instance
it provides an opinionated structure and setup
automatic code-splitting
it streamlines the building of server-side rendered Vue apps
it helps you get the most of your universal web app without a server
easy setup using the command-line with the starter template
3. Why Would You... Not Use Nuxt.js? 7 Drawbacks
The very question that sparked the idea of this blog post in the first place.
You'll hardly find any cons to using Nux. For this, you need to dig a bit deeper and look beyond the huge pile of online content on the common topics:
Nuxt vs Next
Nuxt vs Vue
Nuxt Universal vs SPA
N Reasons to Use Nuxt.js
and so on...
So, let's dig out some... disadvantages that you might want to consider before you just jump on the Nuxt bandwagon:
3.1. Common Plugins that Don't Exist or Which Aren't that Solid
There are Vue plugins designed to work on the client-side only (the server just wasn't added to the "big picture" when they were being developed).
So, do keep that in mind.
Also, you might discover that there are common plugins and components (e.g. Vector maps, Calendar, Google maps) that, well, don't exist.
When they do exist, they might not be as solid as you expected, since they're not properly maintained.
3.2. Getting Custom Libraries to Work with Nuxt with Can Be Challenging
Add this issue to your list of "the biggest disadvantages to using Nuxt.js", especially if the timeline for building your Vue.js app is a tight one.
Addressing it might take you more time than planned.
3.3. High Traffic Can Be Particularly Heavy on Your Server
This inevitable server strain in the case of a large, high-traffic application is another reason not to use Nuxt.js.
At least if this inconvenience weights heavier on your evaluation list than the pile of benefits does.
3.4. Debugging It Can Get Painful
"When things break, trying to dig down into what the hell broke can be a serious pain." (source: Reddit.com)
This is one of the most frequently reported issues with using Nuxt.js.
An issue that becomes exponentially frustrating as your Vue app project gets more and more complex:
When trouble strikes you only get a conventional error message. No clue, whatsoever, about where you should start your "investigations" in order to track down the "culprit".
3.5. There's a Relatively Small Comunity Behind It
And that can only translate as:
the product documentation is not that extensive
fewer resources for you to dig into at need
3.6. Fetching Data on the Server Takes Place At the Page-Level Only...
This means that you need to load data into a Vuex store or pass it all down via props.
A source of... frustration that you should be aware of before you decide whether to use or not to use Nuxt.js.
3.7. You Need to Get "Tangled Up" in More Complex Plugins or Components
If you need to build a particularly flexible Vue app — say you need to render the contents of a slot in another component — you'll have to render various JSX/functions.
The END!
These are the 7 main reasons to (at least) doubt whether Nuxt.js is an invariably good option for your SSR Vue project.
Have you identified other drawbacks, limitations or simply small, but annoying inconveniences to using Nuxt.js?
If so, feel free to share them in the comments down below, so we add them to the list!
Image by Gerd Altmann from Pixabay
Adrian Ababei / Dec 18'2019
"Our goal is to have you relax and know that your tax and regulatory compliance are on cruise control." Just mind you don't... relax too much, as one of Capex CPA's clients, for you risk waking up to a brutal reality: huge payroll year-end mistakes.
It's your choice:
you learn from our immense mistake of hiring this Chartered Professional Accounting firm Brampton
you knowingly expose your company's accounts to a level of incompetence that's... off the charts
Until here, I might sound to you just like another revengeful former client of a Chartered Professional Accounting firm in Mississauga, am I right?
Especially since it's one of the 5-star teams of Chartered Professional Accountants that I'm referring to. A highly reputed, high ranked Chartered Professional Accounting firm in Toronto according to its clients' reviews.
Well, we've already taken the "reputation" bait, ourselves, so... we get you:
The impeccable reputation forms a thick concrete wall around this team of Brampton Accountants, hiding their incompetence from the public eye.
But now, let's talk facts. Real facts, shall we?
Here are the reasons why we decided to fire our accountants, Capex Brampton, after no less than... 11 months, during which we "relaxed, knowing that your tax and regulatory compliance were on cruise control":
1. Capex CPA Bampton Got Our Payroll Wrong... 3 Times in a Month
Just make sure you don't rely... blindly on their "experienced and professional staff", for, unfortunately, they live by this motto:
Practice makes it perfect.
Well, in the case of our payroll it didn't make it perfect. It was all wrong, every single time.
We're talking here about a team of Chartered Professional Accountants in Toronto who's repeatedly provided us with the wrong payroll 3 times during the same month.
3 might be a magic number for some, at least in fairytales, but it did not guarantee us any... happy ending.
They "stubbornly" tested our patience and just... shocked us with their incompetence, which is, we have to admit: out of this world!
2. They Overlooked the Fact that Our Funds Were Both in CAD and USD
And we're talking about a Chartered Professional Accounting firm who has been having access to OPTASY's accounts for... 11 months.
This was, indeed, a masterpiece of incompetence mixed with... an overdose of irresponsibility.
But hey, who needs responsible and accountable... accountants, right?
We just need to... "relax knowing that our tax and regulatory compliance are on a... cruise".
Now, there are at least 3 different answers to our legitimate question:
How could this team of Chartered Professional Accountants Mississauga, one with an irreproachable reputation, not see, while managing our accounts for 11 months, that there were 2 different currencies in there? Both CAD and USD...
they're shockingly incompetent (sorry, but it seems to be the keyword of this blog post)
they're dangerously negligent: they just didn't care what currencies the funds in our accounts were... USD, CAD... potato, patato
they knowingly neglected even their very basic responsibilities as a team of Toronto accountants
Pick any answer or pick them all. There's no wrong one here.
3. They Exposed Us to the Risk of Not Being Able to Pay Our Year-End Taxes
The blunders of this Chartered Professional Accounting firm Mississauga kept piling up till we ended up with a year-end payroll filled with mistakes.
We had no other chance but to quickly replace this CPA in Brampton with a professional ("truly" professional) to address all the serious issues in our accounts, so we could go ahead and pay our taxes.
"Irresponsible" is a too soft term to define their work as our Chartered Professional Accountants Brampton over these 11 months.
4. They Demonstrated Their.... "Professionalism" By Claiming for More Money to Fix Their Own Mistakes
"Mistake is human", right? We, too, as a Drupal firm, make mistakes when working on our clients projects.
But how would you call a long sequence of mistakes? Complacency or pure incompetence?
And fixing one's mistakes is... human dignity, isn't it?
Not the case of Capex CPA, who's genuinely replied, when we asked them to address the issues they had caused:
"5k is not enough money to do the work..."
The "work" here being that of fixing the mistakes they, themselves, kept doing throughout the year as the accountants handling our business tax in Toronto.
How would you call that?
Dishonesty, untrustworthiness, lack of a minimal sense of responsibility for one's actions.
And we're referring here to a team of accountants handling Corporate tax Toronto. Accountants!
So-called "professionals" that deal with:
Real Estate tax in Brampton
Business Tax Brampton
Corporate tax
... on behalf of their clients.
To whom we gave free access to our companies' accounts.
In return, after they made not one, but several mistakes while doing our bookkeeping and payroll and we dared to ask them to... clean up their mess, all we got from this "professional" accounting firm handling Corporate tax Brampton was an:
"Oops!"
And a: "Sorry, but there'll be an extra charge if you want us to... fix our mistakes, as well."
Now, we'd appreciate your "brutally" honest answer to this question:
How would you have handeled this situation if you were in our place?
Would you have fired Capex CPA or not?
Image by Robert DeLaRosa from Pixabay
Adrian Ababei / Dec 04'2019
Simple or custom-made? Is it a quick-to-assemble, rather “prototypical” form that you need for your website? Or a more complex, custom-made one? In a Drupal 8 Contact Forms vs Webform “debate”, which Drupal form builder best suits your data collection requirements?
On one hand, you have the convenience of creating your web forms in no time: simple, straightforward, “conventional” web forms. On the other hand, you get to scan through a never-ending list of advanced options and come up with a complex, fully custom-made web form.
That, of course, if you don't mind the time you need to invest in going through all those different form elements and available features and the risk of getting... overwhelmed by tons of field customization options.
Ease of use vs unlimited capabilities...
The convenience of getting your forms up and ready to collect user data in no time vs the chance to tailor some more advanced forms, ideally customized, carrying lots of different field values.
Decisions, decision...
Now, to help you decide, here's a more detailed Drupal 8 Contact Forms vs Webform comparison. Weigh each one of the 2 form modules' benefits and drawbacks, set them against your own needs and... make the choice:
1. The Contact Forms Module
Being part of Drupal core, there's no need to download and install the module.
Just go to Structure>Contact forms. Next, choose either to opt for the default form or to set up a new one: click the “Add contact form” button.
Once in the form creation screen, enter your form's values in the predefined fields that you have there:
give the form a name in the “Label” field
enter the email address where all the form submissions will be sent to (most probably your site admin address) in the “Recipients” field
enter your “Thank you” text in the “Message” field there; this will be the “thank you” text line your users will see once they hit the “submit/send” button
in the “Redirect path”, enter the URL to the page that you want them to get forwarded to after they've submitted the forms (that if you don't want them to be redirected back to the homepage, by default)
click “Save” and there you have it: a simple form, with all the basic, must-have field values, added to in no time
Of course, that doesn't mean that you can't further explore the given features and maybe add a few more fields and even styling options.
For instance, you could “Edit” your newly created form. Just select it in the “Contact Forms” screen and, scrolling down the options in the drop-down menu opening up, click the “Manage fields” option.
Click “Add field”, then “select a field type” – Text(plain), let's say – enter the “Label” and configure its settings.
Furthermore, if you want to style your form a bit, hit the “Manage form display” tab and... opt for a placeholder, for example. Next, explore the options available in the “Manage display” screen. For instance, you get to decide if you want your field label to be hidden, inline or visually hidden...
In short: in a Drupal 8 Contact Forms vs Webform comparison, the first form builder will always outshine the latter when it comes to ease of use.
It empowers you to set up a simple form quick and easy...
2. The Webform Module
Now, if Contact Forms is a rather minimalist form builder, the Webform module is a feature-rich, powerful one.
The customization features that it ships with go from email notifications to fine-grained access, from statistic collection of data to delivering results in a CSV format. From exporting data in various formats to... conditional sorting and filtering.
In other words, with Webform sky is the limit when it comes to the contact form that you can create.
It can go from a basic one to a highly complex, multi-page form. One made of lots of elements, advanced options for the user to select from, settings and features for you to leverage in the back-end...
But, let's keep in mind that it's a contributed module, so you'll first need to download it from Drupal.org.
Next, go to “Structure” and hit the “Webforms” tab. Then, click the “Add webform” button and, in the next screen popping up, give your new form a name (enter it in the “Title” field).
You'll be automatically forwarded to the “Build” tab, which is where all the “magic happens”. Once you click the “Add element” button, you'll get to “swim through” a sea of lots and lots... and lots of form elements (known as “fields” in Contact forms) to choose from. Ranging from basic to really advanced ones...
Let's assume that you'll want to add a “Text field” element. Click the “Add Element” button corresponding it, then scan through all the new customization options listed up in the “Add Text field element” screen opening up next...
Feel free to add other elements to your webform: a “text area” maybe, an “email” element, as well...
Note: do keep in mind that, once you've settled for the final fields/elements to be included in your web form, you can always change the order to get them displayed in. Just drag and drop them till they fit that predefined order in your mind...
Also, you can check/mark them as “Required” and turn them into “must fill in" fields, as opposed to optional form fields.
Note: feel free to edit that “Thank you” page that your webform will automatically forward users to. How? By clicking “Back to form”>"Settings”>"Confirmation” and selecting from the different options that you have there:
enter your own Confirmation title (e.g. “Thank you!”)
customize your Confirmation message
3. Drupal 8 Contact Forms vs Webform: Key Differences
Now that we've run our spotlight over each one of these 2 form building tools, let's make an inventory of the differences that we've identified:
first of all, it's obvious that the Webform module gives you more control over your web forms' design
also, unlike Contact Forms, it supports conditional emails; you get to send an email to a specific user in your list based on conditions associated with the value of certain elements in your form
Webform enables you to add basic logic to your web forms
… it comes packed with tons of advanced options, ranging from JS effects to conditional logic, to submission handling, etc.
Contact Forms, on the other hand, allows you to set up a simple contact form in the blink of an eye; you skip the tedious process of scanning through lots and lots of options, settings, and complex features
Webform allows you to create your forms either in a YAML file or in its the admin-friendly UI
also, Webform comes as a “cluster” of submodules – Webform REST, Honeypot, Webform Views, SMTP, Webform Encrypt, etc. – which are “responsible for” its multiple capabilities
4. In Conclusion...
The conclusion of this Drupal 8 Contact Forms vs Webform “debate” is quite simple:
If you need a basic form on your website and you need it built fast, go with Contact Forms. Being included in Drupal 8 adds convenience...
But if you want to customize your form (and you have the time), to style it to your liking and “turbocharge” it with advanced features and options, go with Webform.
It's a much more powerful and feature-rich form builder, perfectly suited for your complex requirements...
Image by Tumisu from Pixabay
Adrian Ababei / Apr 24'2019
If only there was a... button that you could just press to convert your app to Android or iOS, right? Or if only a quick and easy recompilation process had been enough. Or if the “Let's just make it look similar” approach was your “winning card”... There is no such thing as “easier way” to port an Android app to iOS and vice versa.
Instead, there are essential aspects to consider and to adjust your whole app porting process to, meant to stir you in the right direction:
navigation
design considerations/UX
screen size and resolution
code and essential app architecture differences
3rd party services, frameworks, extensions, and used libraries
And, as you might just guess, the list is incomplete. For it includes other factors, as well, such as device support, customer and business model considerations and so on...
To keep your app's architecture intact, while porting your app between Android and iOS — 2 platforms with drastically different UIs and core structures — considering the above-mentioned 5 factors becomes crucial.
Therefore, let's detail them, shall we?
But What Does App Porting Actually Mean? Its 4 Key Stages
Let's start with some sort of definition of the whole process:
By porting your mobile app you're changing or rewriting its code so that it should work on a different mobile OS than the one that it's been initially developed for.
Clear enough?
“How long does it take to port an Android app to iOS and vice versa?” you might ask yourself.
Usually from 1 to 6 months, but it depends greatly:
on your app's complexity
on its core architecture
on the entire ecosystem of libraries that it uses, on its design particularities
on the business logic behind
Speaking of which, analyzing precisely the driving business logic is as critical as it is underrated by developers who usually stick to: adapting a platform and eventually writing the needed extra code.
“And what are the essential steps to take to porting my app?”
Glad you asked. Here are the main stages that an effective mobile app porting process should include:
analysis and plan
technical assessment
the porting itself
intensive QA
1st Factor to Consider When You Port an Android App to iOS: Navigation
Navigation is the factor that "miles" sets apart the user behavior on Android phone from the user behavior on iPhones.
Here's why:
Android devices are equipped with 3 different buttons: Home, Back and Multitasking button
iPhones only have the home button
Now, imagine tapping a multitasking button as in the Android platform: you can't get away with a simple transfer to iOS. Instead, you'll need to write the proper code for it from scratch.
And there's more to navigation and to the way that it is drastically different from one platform to the other. For instance:
Both horizontally and vertically displayed elements on iOS vs vertical elements only, on Android devices.
Tip: if you wish your iOS app to look similar to its Android alternative, there's always the handy compromise that you can make of placing in-app tabs in the bottom of the screen.
2nd Factor to Consider: Design Considerations/UX
You'll have to reconstruct your app's user interface from scratch to convert it from Android to iOS (or the other way around)!
Face it, deal with it and... adapt your “battle plan” to it!
There's no way around this:
When it comes to UI, Android and iOS are just... worlds apart! Android taps into material design, contrasting Apple's signature flat design.
Now here are the key design elements that you should pay special attention to, along with some tips on how to make their porting... smoother:
icons: each platform provides you with its rich icon library
dialogs
font styles: San Francisco or Helvetica Neue in iOS and Roboto in Android
content navigation
lists
object placement: flat vs hierarchical object placement
text alignment: center aligned test in iOS vs left alignment of the text in Android
buttons: iOS “favors” flat buttons with shadows, whereas in Android you'll find both flat and floating action buttons
Word of caution: when porting apps to Android or from Android, keep in mind the pixels vs points (pt) difference when it comes to measuring icons and font sizes in the two platforms
3rd Factor to Consider: Screen Size and Resolution
Briefly put: it will be conveniently smoother to port an Android app to iOS than vice versa.
Why? Because in Android you have a varied collection of screen sizes and resolutions at hand, whereas in iOS it's significantly lighter.
So, if it's an app porting to Android that you're planning, do take into consideration all those screen resolutions that are missing in iOS.
4th Factor to Consider: Your App's Essential Architecture
And here's the right approach to adopt when you port an Android app to iOS (or vice versa) and you're preparing to build its new architecture:
Identify the minimum OS version that your ported mobile app should support and set up its architecture accordingly.
5th Factor(s) to Consider: Frameworks, Libraries, Extensions, Code
Your current app's “infrastructure” of libraries, extensions, 3rd party services and frameworks play a critical role.
A “too critical role” not to turn it into an essential factor to consider once you decide to port your app to a new OS.
Therefore, for each one of the used libraries that's not compatible for cross-platform usage you'll need to find a suitable equivalent. And it goes without saying that this calls for:
A proper testing of each given framework and 3rd party library, to know for sure which ones support both OS and which ones don't.
The good news is that most of them do support them both, making it smoother for you to duplicate most of your app's basic functionalities when converting it to another OS.
Now when it comes to the aspect of code, the fact that the 2 platforms use different programming languages influences greatly the way you should port an Android app to iOS:
Kotlin and Java are used for building Android apps, whereas Swift is used to develop iPhone apps. Therefore, you can't get away with simply compiling your app's current code into its new ported version.
Note: I know what you might be thinking, that both OS support the C-code instead and so, that you could transfer your codebase to the other platform. Yet, it has already been proven that porting apps to Android from iOS calls for a complete rewriting in a different language.
How long would it take you? It depends greatly on your app's feature set, on the used 3rd party libraries, complexity etc.
Final Word
As you can see, once you decide to create a “clone” of your iOs app for the Android platform or vice versa, you'll need to take “recompilation” out of your mind.
Porting your app won't be that simple!
With the 2 platforms having completely different user interfaces and core structures:
careful planning and in-depth analysis (and yes, I'm thinking business logic here) becomes crucial
taking into account all those elements that set these OS worlds apart (interface, navigation...) and adjusting your porting strategy accordingly is the only effective way to port an Android app to iOS or vice versa
Adrian Ababei / Jun 21'2018
Sorry to disappoint you, but: there's no such thing! No such thing as “the best way to style React components”. Or “the most effective approach” or “the currently best option” for styling reusable components within your application.
What you do have, instead, is:
“The most popular or commonly-used ways of styling components!”
4 of them, actually.
And rating one of these approaches as “the best” is totally up to you:
to your personal preferences
to your React app's level of complexity
to what precisely it is that you need to style in your React project
and to your feature needs
Is it just a few style properties that you need to add? Then the inline styling approach suits your “component styling scenario” perfectly.
Or maybe it's a more complex React app that you're working on? In this case, you might want to go for the classic approach: using CSS classes and stylesheets and tying them all together with webpack.
But let's just put each of the 4 popular ways of styling React components into the spotlight and clear the picture for you a bit more!
I'll be highlighting each option's main advantages and drawbacks, so you can knowingly decide which one's the best option for you.
1. The Classic Approach: Using Regular CSS Stylesheets
You always have classes and stylesheets to rely on when it comes to styling. Simply tie them all with webpack after you've imported CSS file:
import './DottedBox.css'
… ensuring, this way, that you have a separate CSS file for each one of the components to be styled.
The main advantages of this common approach?
it'll then be easier for you to move between your CSS and the browser
it will streamline overriding or MVT in case you'll need to go in that direction
Yet, there's also a bit discouraging drawback to this approach to styling React components:
Do expect to face all the “standard” CSS problems: potential conflicts between definitions and mutual classes, attribute inheritance (both good and... bad)...
2. CSS Modules
And before we delve into the:
“why” you might rate using CSS modules as “the best way to style React components”
“how” to leverage their styling capabilities
... let us try to define them:
They're CSS files where all animation and all class names get automatically scoped.
Moroever, CSS modules help you “keep things clean” when it comes to all the previously mentioned problems that CSS stylesheets can challenge you with.
They make the most efficient approach to styling React components when you're dealing with complex applications.
And now, here are the steps to take for styling your reusable components using CSS modules:
import CSS file: import styles './DashedBox.css'
next, access className as you access to the object
And here you have 2 options at hand:
:local(.className) if/when you opt for create-react-app due to webpack configurations
.className in case it's your own React boilerplate that you're using
“OK, but how do I make my CSS modules work with Webpack now?”
A legitimate question that you might be asking yourself right now.
Here's how:
you simply include the modules early mentioned
next add the loader here below to your webpack.config.js file:
. . .
{
test: /\.css$/,
loader: 'style!css-loader?modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]'
}
. . .
3. Styled Components: Is This the Best Way to Style React Components?
“It is if working with class names to compose stylesheets is not really... your thing.”
Take it as a more “non-traditional” way of styling components, where you:
Create encapsulated styles and integrate them with the props of your components. In other words: instead of using className, you'd be using style attribute.
And styled-components — a JavaScript and CSS “combo — are no more than a library enabling you to use component-level styles within your React app.
Or, you can also see them as a “wrapper component”: mapped to HTML tags in order to style itself and its child elements.
This way, you can easily write regular CSS in your JS file.
The main advantages?
you get to store all the styling within the component
… to have separate and reusable UI for your React stateful/stateless components
… to build “isolated” components
And now, let me take you through all the steps required for leveraging this library's styling capabilities:
fist, just install the library itself: npm install styled-components –save
next, set up a variable by selecting a specific HTML element, to store your style keys const Div = styled.htmlElemnet`color: pink`
and finally, use that variable's name as a wrapper <Div></Div> type of React component
4. Inline Styling
This might just be the best way to style React components for you if it's only a few style properties that you need to add.
Don't expect for inline styles to be specified as a string in React:
They're not! Instead, they're mentioned with an object:
whose key is the style name's camelCased version
whose value is usually a string, the style's own value, actually
And you have 2 options at hand for “triggering” the styling capabilities with this approach:
you create a variable storing style property and get it sent through to the element like style={nameOfvariable}
you pass the styling — style={{color: 'pink'}} — directly
Still, don't get overly “enthusiastic” about using this approach to styling! At least not until you've taken note of all the challenges that it presents, as well (and there are quite a few):
you won't be able to use pseudo-classes, one of the core features of CSS (:active, :hover, :focus etc.)
expect duplication in markup each time you'll use a specific component: you won't be having your styles in your JS only, meaning that doing server-side rendering will lead to duplication, to using repetitive rules and the same style code for multiple components
you won't get any media queries: you're left with the solution of using a JS approach for “juggling with” different screen variations
and you can't use vendor prefixes, nor override a rule on the very same selector
In a few words: using inline styling might just not be the best way to style React components if:
... It's a UI-heavy, complex application that you're working on and this is due to the approach's highly restrictive usage.
Nevertheless, if you still consider that this option suits your preferences and your app's feature needs best, go for it! You could always use a library such as React JSS, Readium, React style to deal with the above-mentioned inline styling limitations.
The END! These are 4 most widely-used ways of styling components in React, along with their key benefits and their most discouraging drawbacks.
Which one would you rate as “the best way to style React components” according to your personal preferences and to your current app's “needs” in terms of styling capabilities?
Adrian Ababei / Jun 14'2018
Here's how the ideal decoupling Drupal scenario looks like:
Stripping Drupal to its essential role, that of a robust and flexible content repository, no Drupal expertise needed. Then using it to back your front-end with; one that you'd be free to build by leveraging any modern (JavaScript) technology of your choice.
… a Drupal back-end content store that would still preserve all its content editing and managing functionalities, needless to add.
Luckily, this is no longer “daydreaming”. Not since Reservoir, the headless Drupal distribution, has been available.
Here are some of its “promises” or well-known challenges, if you prefer, that this distribution's geared at solving:
to make Drupal far more accessible (cutting the intimidating Drupal setting up and configuration out of the equation) to developers of all stripes
to empower developers with all the best practices for building their Drupal-backed front-ends quick and easy
to provide an opinionated starting point enabling any developer to build a Drupal content repository backing his non-Drupal application with... no Drupal knowledge needed, actually
Your Current Situation: Why Would You (Even) Consider “Headless” Drupal?
Here you are now, dealing with the pressure of:
having to deliver content agnostically across any given channel and device: single-page JS apps, mobile apps, digital signage, AR and VR-driven content, IoT apps etc...
… all while storing it (content) in one single place
providing your editorial team with a... way to edit, manage and overall administrate content conveniently easy, via an editor-friendly UI
… independently of the development team, of course
finding a way to enable your developers to easily send content across this entire “ecosystem” of channels, devices and platforms
In other words: you're grappling with the challenge of making Drupal ideally accessible to your (non-Drupal) developers; so they can easily build their Drupal-based content store enabling them to deliver content to any given device.
… to serve it to any given app/site.
And this definitely calls for a decoupling Drupal approach.
Decoupling Drupal: The Most Discouraging Challenges You Must Be Facing
Let's assume that you're already considering headless Drupal as a solution for your current challenge, that of delivering content to multiple channels, devices, platforms.
Whether you're planning to decouple Drupal for:
building a Drupal-backed front-end, leveraging one of your modern JavaScript frameworks of choice
or using it as a content store for your non-Drupal app
Then, it's these specific challenges that you must be facing right now:
your non-Drupal developers are having trouble maneuvering Drupal content; they're not familiar with all the dials and knobs needed for making the most of Drupal's REST API
Drupal's serialization format is... alien to them
there's no starting point or well-defined best practices for non-Drupalists, that would ease their way to turning Drupal into a content repository
… one that they could back their front-ends with
True story!
And still, there is hope...
5 Reasons For Being “Skeptical” About Distributions
You must be legitimately cautious right now when it comes to using an API-first distribution for Drupal. And that's due to some bad experiences with... distributions.
Now let me try and guess some of your “fears” regarding Reservoir:
that it might turn out to be overly complex
that you risk getting “stuck with” architectural debt
that its maintainers might someday lose interest in it
that it's built primarily for other use cases, for scenarios different from your own decoupled Drupal implementation project
that you risk “inheriting” bugs in features that you haven't even used
And the list of reasons why you're not yet jumping on this decoupling Drupal trend could go on...
Introducing Reservoir: The Headless Drupal 8 Distribution! How Is It Different?
Before putting it into the spotlight and giving it a “full scan”, let me try to read your mind and identify the questions that you must be asking yourself right now:
“How precisely do I use Reservoir as a content store backing my front-end website or app?”
“Which are the bare essential Drupal modules and core functionality that this distribution comes packed with?”
“How can I leverage these ready-to-use components for decoupling Drupal?”
And now that we've put your valid queries into words, let me try and define Reservoir for you:
1st definition: a distribution for decoupling Drupal
2nd definition: an ideally flexible and minimalist tool empowering developers of all backgrounds to build content repositories for their apps to “consume”
3rd definition: the headless Drupal 8 distribution “specialized” in manipulating content and interacting with it via HTTP APIs
4th definition: a Drupal-based content store with all the web service APIs backed into, so that any developer can jump straight to building his front-end app
5th definition: simply a... content repository; one that just happens to be Drupal-based, as the Reservoir project's maintainers admitted.
Now the 4 key goals behind this distribution for decoupling Drupal — besides that of providing a simple way of building a content repository enabling you to use any technology for your front-end — are:
on-boarding developers or all stripes, making Drupal ideally accessible to... anyone
providing a much-needed opinionated starting point for any type of decoupled Drupal implementation; no Drupal knowledge required
keeping itself away from the scope creep that end-user facing products risk falling into
serving a specific decoupled use case
Decoupling Drupal Made Easy & Accessible: Key Reservoir Features
“But how does Reservoir make building Drupal-based content repositories so much easier than other... distributions?”
“How precisely does it make Drupal accessible to non-Drupal developers, as well?”
You're more than entitled to ask yourself that...
Therefore, let me outline here the out-of-the-box Reservoir features geared at speeding up any decoupled Drupal implementation. Regardless of the developer's background:
an opinionated selection of API-first/ web services modules — Reservoir offers each developer a much-needed starting point/”push” so that he can ramp up and have his content stores built in no time: Simple OAuth modules here included
quick and easy access to the content back-end via JSON API
auto-generated documentation (API documentation), that gets automatically updated, as well, as you're browsing it, as your content model changes
OpenAPI format export, that supports hundreds of tools integrating with the OpenAPI specification
easy-boarding/tailored UI — expect a “welcoming tour” once you've installed Reservoir, one focused on getting you familiar with modeling and managing content, web service APIs, mapping out new content models etc.
a permission system and content editing UI empowering your editorial team to easily manage content
SDKs, libraries and references — included in the Waterwheel ecosystem — so that your development team can skip the time-consuming API learning phase and jump straight to “attaching” Drupal back-end content to their front-end apps
Note: Reservoir, the distribution for decoupling Drupal, deliberately shakes off some of Drupal's functionality that's irrelevant for content repositories (modules such as Breakpoint, Views, Content, the user-facing front-end etc.)
For we couldn't even talk about speeding up your decoupled Drupal project when there's an unnecessarily heavy weight of Drupal modules and features “dragging down” the whole implementation process, right?
Wrapping Up: What Reservoir Aims At Is...
... enabling your developers to jumpstart building self-hosted content repositories capable to serve any given front-ends.
Front-ends that they get to build independently, tapping into the technologies they prefer, on a project-by-project basis.
Pretty convenient, don't you agree?
Adrian Ababei / May 09'2018
You sure didn't expect it to take more than... 2 minutes (3 at most) to add a Drupal 8 Webform to a content type on your website and yet...
What's the “catch”? Is there a "magic" tab that elopes you? Haven't you installed your Webform Drupal module properly?
Or maybe it's the UI itself the real culprit for turning what should have been a "ridiculously intuitive operation into a time-consuming (and hair-pulling) one?
Let us lend you a hand! Let us help you put an end to your "turmoil".
But First: A Few Words About the Webform Drupal Module
Surpassed in popularity only by the Views Drupal module, Webform shouldn't miss from your Drupal toolkit. For it makes the most "usable" tool to rely on for building your custom contact forms/user registration forms/surveys.
A far more efficient solution than building content types leveraging the Field module or using CCK.
Drupal 8 Webform Module
... ships with a whole different code base than that of its “predecessor” and makes an even more powerful, feature-richer form builder enabling you to put together:
flexible
rich
maintainable
… webforms on your Drupal 8 website
Moreover, its capabilities don't limit to the forms' building and publishing, but extend to:
sending confirmation forms and client notifications
collecting, storing and downloading form submission data as CSV
Your Current Scenario
Here's how we see your current “situation” in... 4 steps:
First, you installed your Drupal 8 Webform module
Then you rushed to add a webform to a content type
… so you went to admin/config/content/webform and checked your content type, next you saved your webform settings
And then ... you “hit a blank wall”!
No clue whatsoever where to go next to attach your webform to your content type...
The Solution to How to Add a Webform to a Content Type
Now the above screenshot's “transcription”:
You navigate to your Content type's edit page: /admin/structure/types/manage/[ContentTypeName]
See the “Webform” tab, on the bottom left side of the screen, right under the “Menu Settings” tab?
Just go ahead and enable it and your webform will get automatically attached to that specific content type
Tada! This is how you add a webform to a content type in Drupal!
You just knew it couldn't be anything more complex than a two-minute job, right?
How to Embed a Webform Inside a Node Content: 2 Solutions
In other words: no matter which way you take it, you'll reach the same “destination”.
Here are the 2 methods available to you:
you go ahead and put together a custom Panel page for your node; one with the content area incorporating both the “node being viewed” and the custom block displaying your web form
you leverage the Webform module's power: simply create your web form via the module's user-friendly UI and then just add your form to your “target” content type
Tada... again!
The END of our more or less “enlightening” little tutorial on how to add a Drupal 8 Webform to a content type on a Drupal site. Good luck with your... form building!
Adrian Ababei / Nov 30'2017
What are Drupal 8 distributions anyway? Why bother using one: what would you gain by using one instead of building your Drupal 8 site from scratch? And, most importantly: which are the best Drupal 8 distributions to choose from?
… the top-rated ones, both by other companies already using them and by Drupal experts, as well?
There are lots of different Drupal Distributions: Commerce Kickstarter, Open Atrium, Drupal Commerce, etc. build for different versions of Drupal. Which ones are the best?
Let's jump straight ahead to the answers you're looking for now, shall we?
First Things First: What Is a Drupal Distribution After All?
“A Drupal distribution packages a set of contributed and custom modules together with Drupal core to optimize Drupal for a specific use case or industry." (Dries Buytart, Distributions Remain a Growing Opportunity for Drupal)
Take it as an all-in-one-place or a conveniently quick and easy-to-install package.
One which, once “unwrapped”, delivers you all the site-specific features and business use-case/industry-specific functionality that you need:
Drupal core
precisely those contributed and custom modules that you need
themes
predefined configuration
installation profiles
libraries
Bottom line: it's Drupal + additional software components (strategically assembled and preconfigured) that you get with a Drupal distribution software.
One that will turn setting up your use-specific Drupal 8 site into a breeze! “How to install a Drupal distribution?” quickly turns from a hard nut to crack into nothing but a child's play.
Just imagine how much time and valuable resources you'd otherwise invest in:
scanning through the overwhelmingly rich collection of Drupal modules
figuring out which are THE ones catering to your specific use case or industry
installing all the needed elements (and here we're not referring to Drupal 8 modules only) one by one
And here we can talk about 2 types of Drupal distributions:
the full-featured ones
the quick-start tools
Key Advantages of Using One Over Building Your Site From The Ground Up
Before we push forward, into the spotlight, the best Drupal 8 distributions to choose from, let us outline what you'll gain, precisely, from making this decision:
Using a Drupal distribution over setting up your website from scratch.
launching your website turns into a matter of a few... hours; instead of delving into a load of thousands of modules yourself, the preconfigured site that you get by choosing a software distribution delivers you everything you need in a single download: wrapped up in one installable package!
by comparison, the “traditional” way of setting up your site would grant you access to Drupal core only; any additional functionality needed calls for... additional downloads
maintaining your whole ecosystem of modules and other site components becomes less time-consuming: one single update is enough for all Drupal modules and features (vs “hundreds” of them in a conventional Drupal site build scenario)
And now since selecting the proper Drupal distribution, the one that best suits your specific type of site, your business use case, and industry, is key, let us reveal to you the top-rated ones to consider choosing from:
And Here Are The 7 Best Drupal 8 Distributions
1. Lightning
Empower your editorial team and you'll get (even) better content on your Drupal 8 site!
With the Lightning Drupal distribution for enterprise, you get to turn crafting, adding, editing, and publishing content into a rich authoring experience!
How does it work you say?
Practically Lightning's built to "fuel" the editorial experience with these 4 modules' powers combined: Workflow, Media, Layout, and Preview.
Hence, content editors get all their feature/functionality needs satisfied for creating great content (and handling content editing operations) with great ease.
2. Varbase
The "nitty-gritty" of any Drupal web project!
This is what you'll get once you "unwrap" your package with the "Varbase" name tag on!
Basically, the essential modules, configurations, features, and functionalities that any Drupal 8 site needs are all bundled up in this starter kit, at a click's distance!
Get all these necessities downloaded and installed and give your site's development a major speed boost.
3. Contenta
Planning to jump on the decoupled Drupal bandwagon? To progressively decouple your Drupal 8 site maybe?
Then Contenta, the API distribution for Drupal 8, makes your best "ally" in turning your decoupling Drupal project into a success story!
What it does, precisely, is it eases the overhead of making a decoupled architecture work (or simply “trying it on”, to see first whether it fits you or not):
it provides you with an API-ready platform (admin configuration here included)
... demo content
... and even example front-end applications
4. Reservoir
Here's another API-first Drupal distribution, (still) an experimental one, that you can rely on for supporting your Drupal decoupling initiative.
... if you were looking precisely for a flexible and easy to use tool for building a Drupal content repository that your front-end app could easily access via HTTP APIs.
But what makes Reservoir one of the best Drupal 8 distributions?
it takes the burden of modeling and managing content off your shoulders
it enables your team of developers to set up a basic, yet functional content back-end, all while preserving the rich content editing experience (with all the functionality and features that editors get "spoiled" with) that Drupal 8's well famous for
Note: surprised that Contenta and Reservoir have made it to our "best Drupal 8 distributions" list? Don't be! The 2 API-first distributions might still be community-driven experiments. Yet, all the potential they "promise" to unlock in a digital landscape where the channel/device/design-agnostic trend and the API-first approach rule is not to be underestimated.
5. Thunder
Out-of-the-box publishing technologies (Riddle Interactive Content, Facebook Instant Articles) and modules from industry partners (Valiton, Nexxt.tv, Acquia) is what you'll get along with your Thunder "package".
In short: all you need in an all-in-one the bare necessities and more addressing all your professional publishing needs!
6. LISSA Kickstart
A Drupal distribution built to help you streamline your events and client notifications management and publishing process.
What you'll get specifically is a Drupal-based technology stack for real-time messaging in second screen apps. One which, as a media company, you get to leverage for:
pushing notifications to your clients
publishing video stream (live or on-demand)
... with convenient ease
7. Open Social
By far one of the most popular Drupal distributions, Open Social couldn't have possibly missed from our top including the best Drupal 8 distributions.
Go for it if it's a:
social community platform
intranet solution
portal
or any other Drupal-powered social project that you're planning to build
It will dramatically speed up the development process as it provides you, right out-of-the-box, with all the elements that your social community site could need:
Notifications
Timeline
Events
Follow
Groups
And this it IT! Our own selection of the very best Drupal 8 distributions to consider as "candidates" for your own specific Drupal project. Select the one that best fits your project's specific use case, then weigh its advantages and... decide how you'll invest the time that you will have saved using it (instead of building your site from scratch).
Adrian Ababei / Nov 23'2017
“By our powers combined...” Let's imagine the representatives from all major web browsers saying this line when they joined forces, in 2015, for creating a whole new format for compilation to the web. When the WebAssembly support “revolution” began.
And there's no one in the digital landscape who can honestly admit that they saw this coming!
That after only 2 years all four major web browsers, Firefox, Chrome — the first 2 to enable support for WebAssembly by default — Safari and Edge — that joined the WASM “gang” the past few weeks — would officially run WASM code on the web.
How did it all begin? How did we get this far and (most of all): what can we dare to expect from a WebAssembly-influenced future of web?
An Unexpectedly Promising Start
Let's start with the “I have a dream...” type of beginning!
Work on WebAssembly started in 2015. Its team of engineers' dream (a dream nourished by all other web browsers) was to create a technology/set up a standard (or “format” if you prefer) for rendering application logic as optimized bytecode.
… for compiling JavaScript code into WASM format which injects web apps, even the most complex, “bulky” ones, with high performance and increased security.
With near-native speed!
By the end of 2016 the team of visionaries — the W3C Community Group — had already added the last “strokes of brush” to the new WebAssembly standard's core features.
And only 7 months later, Google, Mozilla and Microsoft were already offering enabled WebAssembly support in their browser previews.
A major boost and a positive shake-up for the development team behind it, which no later than March 2017 was already concluding work on the new standard. And a consensus of all major browser vendors on the initial version of WebAssmely version was reached.
Then, it simply followed its roadmap and started to stir waves in the digital arena:
“Will WebAssembly mark the end of traditional JavaScript-based apps and the new era of native-app-alike... alternatives?” “Is WebAssembly The “Death” of JavaScript?”
From then on, in the months to come, WebAssembly support started to be shipped along with the newest versions of all the 4 major web browsers.
The WebAssembly Standard: Benefits That You Can Reap
And the valid question that you might be asking yourself right now must be:
“And how do I benefit from this new standard? From the WebAssembly support now enabled, by default, in ALL 4 major browsers?”
Here's how:
it will turbocharge your bulky, complex app/modern website with near-native performance (with no need for a plugin); it's proven that the low-level bytecode format that it uses compiles JavaScript code into lighter code: a sustainable use of bandwidth on mobile devices & improved page loading times
it “frees” your development team from “JavaScript's tyranny”, so to say; using WebAssembly as a code compiler they're now “tempted” with a collection of languages to write their code it, wider than ever before... code which they can compile straight to wasm, without the need to transpile it to JavaScript beforehand
the ideally compact WASM format acts as a “turbocharger” which transmits files at high speed over the wire and (most importantly) gets them loaded as JavaScript modules!!!
not only that WASM “was designed from the ground up to be fast” (Jay Phelps, Netflix senior software engineer, said), but also to guarantee you a higher level of protection: the WASM format code is much safer since it executes within the web browser's own security sandbox
bytecode, thanks to its conveniently structured data format, is easier for web browsers to read and parse
What WebAssembly Support in All Browers Means for Developers?
As for your development team, as already mentioned, using the WebAssembly code compiler opens the gates to a whole new world of options: C, C+, Rust...
With more statically typed language support to come!
Moreover, broad Webassembly support at the web browsers' level can only mean that they're free to experiment. Since the great majority of end users now have WASM support automatically enabled in their web browsers of choice.
your team of developers gets to perform their “coding experiments” in a programming language of their choice
compile their code to a bytecode format
… which then the web browser can execute within a virtual machine!
Safari and Edge: The Last 2 Browsers to Join the “WASM” Gang
With Firefox and Chrome as the “early adopters” of the Webassembly standard, it was about time that Apple and Microsoft shipped WebAssembly support in their Safari 11.0, respectively EdgeHTML 16 browser versions, too.
And it's finally a wrap! It's been a few weeks already since all 4 major web browsers are officially capable to run WASM-formated code.
What Next? WebAssembly In the Foreseeable Feature
In other words: what does using the WebAssembly code compiler at its full potential mean?
It's designed to make it possible for any kind of app (the largest ones, with a high demand of CPU, being the main target) to run on the web reaching the same performance as if it would if it was running locally, on the end user's PC. As if it was a native app.
What do you think? Will WebAssembly mark the “birth” of a new kind of native-like apps running on the web instead?
… and developers' “liberation” from the preconception of a “universal language”?
Adrian Ababei / Nov 21'2017